## **內存泄漏（memory leak ） 內存溢出 （out of memory）** ## **內存泄露 ：** 是指程序在申請內存后，無法釋放已申請的內存空間就造成了內存泄漏，一次內存泄漏似乎不會有大的影響，但內存泄漏堆積后的后果就是內存溢出。我們知道了內存泄漏的原因而內存溢出則有可能是因為我們我們多次內存泄漏堆積后的后果則變成了內存溢出 ### **內存溢出**： 指程序申請內存時，沒有足夠的內存供申請者使用，或者說，給了你一塊存儲int類型數據的存儲空間，但是你卻存儲long類型的數據，那么結果就是內存不夠用，此時就會報錯OOM,即所謂的內存溢出，簡單來說就是自己所需要使用的空間比我們擁有的內存大內存不夠使用所造成的內存溢出。 ***（例如全局變量一直在用沒有銷毀 導致變量內存越來越大） 過程就是內存泄漏 導致的結果就是內存溢出*** 內存泄漏的分類（按發生方式來分類） **常發性內存泄漏**。發生內存泄漏的代碼會被多次執行到，每次被執行的時候都會導致一塊內存泄漏。 **偶發性內存泄漏。**發生內存泄漏的代碼只有在某些特定環境或操作過程下才會發生。常發性和偶發性是相對的。對于特定的環境，偶發性的也許就變成了常發性的。所以測試環境和測試方法對檢測內存泄漏至關重要。 **一次性內存泄漏。**發生內存泄漏的代碼只會被執行一次，或者由于算法上的缺陷，導致總會有一塊僅且一塊內存發生泄漏。比如，在類的構造函數中分配內存，在析構函數中卻沒有釋放該內存，所以內存泄漏只會發生一次。 **隱式內存泄漏**。程序在運行過程中不停的分配內存，但是直到結束的時候才釋放內存。嚴格的說這里并沒有發生內存泄漏，因為最終程序釋放了所有申請的內存。但是對于一個服務器程序，需要運行幾天，幾周甚至幾個月，不及時釋放內存也可能導致最終耗盡系統的所有內存。所以，我們稱這類內存泄漏為隱式內存泄漏。 ### **內存泄漏的解決方法：** 內存泄漏也許是因為活動已經被使用完畢，但是仍然在其他地方被引用，導致無法對其進行回收。我們只需要給對活動進行引用的類獨立出來或者將其變為靜態類，該類隨著活動的結束而結束，也就沒有了當活動結束但仍然還被其他類引用的情況。 資源性對象在不使用的時候，應該調用它的close()函數將其關閉掉。。 集合容器中的內存泄露 ，我們通常把一些對象的引用加入到了集合容器（比如ArrayList）中，當我們不需要該對象時，并沒有把它的引用從集合中清理掉，這樣這個集合就會越來越大。如果這個集合是static的話，那情況就更嚴重了。 需要在退出程序之前，將集合里的東西clear，然后置為null，再退出程序。 WebView造成的泄露，當我們不使用WebView對象時，應該調用它的destory()函數來銷毀它，并釋放其占用的內存，否則其長期占用的內存也不能被回收，從而造成內存泄露。 我們應該為WebView另外開啟一個進程，通過AIDL與主線程進行通信，WebView所在的進程可以根據業務的需要選擇合適的時機進行銷毀，從而達到內存的完整釋放。 ### **內存溢出的原因及解決方法：** 內存溢出原因： 1.內存中加載的數據量過于龐大，如一次從數據庫取出過多數據； 2.集合類中有對對象的引用，使用完后未清空，產生了堆積，使得JVM不能回收； 3.代碼中存在死循環或循環產生過多重復的對象實體； 4.使用的第三方軟件中的BUG； 5.啟動參數內存值設定的過小 內存溢出的解決方案： ****第一步，修改JVM啟動參數，直接增加內存。(-Xms，-Xmx參數一定不要忘記加。)**** **第二步，檢查錯誤日志，查看“OutOfMemory”錯誤前是否有其 它異常或錯誤。** **第三步，對代碼進行走查和分析，找出可能發生內存溢出的位置。** ## ****重點排查以下幾點：**** 1.檢查對數據庫查詢中，是否有一次獲得全部數據的查詢。一般來說，如果一次取十萬條記錄到內存，就可能引起內存溢出。這個問題比較隱蔽，在上線前，數據庫中數據較少，不容易出問題，上線后，數據庫中數據多了，一次查詢就有可能引起內存溢出。因此對于數據庫查詢盡量采用分頁的方式查詢。 2.檢查代碼中是否有死循環或遞歸調用。 3.檢查是否有大循環重復產生新對象實體。 4.檢查List、MAP等集合對象是否有使用完后，未清除的問題。List、MAP等集合對象會始終存有對對象的引用，使得這些對象不能被GC回收。 第四步，使用內存查看工具動態查看內存使用情況 如何避免內存泄漏？ 1、在涉及使用Context時，對于生命周期比Activity長的對象應該使用Application的Context。凡是使用Context優先考慮Application的Context，當然它并不是萬能的，對于有些地方則必須使用Activity的Context。對于Application，Service，Activity三者的Context的應用場景如下： 其中，NO1表示Application和Service可以啟動一個Activity，不過需要創建一個新的task任務隊列。而對于Dialog而言，只有在Activity中才能創建。除此之外三者都可以使用。 2、對于需要在靜態內部類中使用非靜態外部成員變量（如：Context、View )，可以在靜態內部類中使用弱引用來引用外部類的變量來避免內存泄漏。 3、對于不再需要使用的對象，顯示的將其賦值為null，比如使用完Bitmap后先調用recycle()，再賦為null。 4、保持對對象生命周期的敏感，特別注意單例、靜態對象、全局性集合等的生命周期。 5、對于生命周期比Activity長的內部類對象，并且內部類中使用了外部類的成員變量，可以這樣做避免內存泄漏： 1將內部類改為靜態內部類 2靜態內部類中使用弱引用來引用外部類的成員變量 如何檢查和分析內存泄漏？ 因為內存泄漏是在堆內存中，所以對我們來說并不是可見的。通常我們可以借助MAT、LeakCanary等工具來檢測應用程序是否存在內存泄漏。 1、MAT是一款強大的內存分析工具，功能繁多而復雜。 2、LeakCanary則是由Square開源的一款輕量級的第三方內存泄漏檢測工具，當檢測到程序中產生內存泄漏時，它將以最直觀的方式告訴我們哪里產生了內存泄漏和導致誰泄漏了而不能被回收。 程序有始有終，我們負責創造它，也需要負責將它銷毀。 原文鏈接：https://blog.csdn.net/jie1175623465/article/details/81121548