Android內(nèi)存泄漏是一個經(jīng)常要遇到的問題，程序在內(nèi)存泄漏的時候很容易導(dǎo)致OOM的發(fā)生。那么如何查找內(nèi)存泄漏和避免內(nèi)存泄漏就是需要知曉的一個問題，首先我們需要知道一些基礎(chǔ)知識。

Java的四種引用

強(qiáng)引用: 強(qiáng)引用是Java中最普通的引用，隨意創(chuàng)建一個對象然后在其他的地方引用一下，就是強(qiáng)引用，強(qiáng)引用的對象Java寧愿OOM也不會回收他

軟引用: 軟引用是比強(qiáng)引用弱的引用，在Java gc的時候，如果軟引用所引用的對象被回收，首次gc失敗的話會繼而回收軟引用的對象，軟引用適合做緩存處理 可以和引用隊列（ReferenceQueue）一起使用，當(dāng)對象被回收之后保存他的軟引用會放入引用隊列

弱引用: 弱引用是比軟引用更加弱的引用，當(dāng)Java執(zhí)行g(shù)c的時候，如果弱引用所引用的對象被回收，無論他有沒有用都會回收掉弱引用的對象，不過gc是一個比較低優(yōu)先級的線程，不會那么及時的回收掉你的對象。 可以和引用隊列一起使用，當(dāng)對象被回收之后保存他的弱引用會放入引用隊列

虛引用: 虛引用和沒有引用是一樣的，他必須和引用隊列一起使用，當(dāng)Java回收一個對象的時候，如果發(fā)現(xiàn)他有虛引用，會在回收對象之前將他的虛引用加入到與之關(guān)聯(lián)的引用隊列中。 可以通過這個特性在一個對象被回收之前采取措施

下面是一個例子：

public class Main { public static void main(String[] args) throws InterruptedException {ReferenceQueue<Object> referenceQueue = new ReferenceQueue<>();String sw = '虛引用';switch (sw) { case '軟引用':Object objSoft = new Object();SoftReference<Object> softReference = new SoftReference<>(objSoft, referenceQueue);System.out.println('GC前獲取:' + softReference.get());objSoft = null;System.gc();Thread.sleep(1000);System.out.println('GC后獲取:' + softReference.get());System.out.println('隊列中的結(jié)果:' + referenceQueue.poll());break;/* * GC前獲取:java.lang.Object@61bbe9ba * GC后獲取:java.lang.Object@61bbe9ba * 隊列中的結(jié)果:null * */ case '弱引用':Object objWeak = new Object();WeakReference<Object> weakReference = new WeakReference<>(objWeak, referenceQueue);System.out.println('GC前獲取:' + weakReference.get());objWeak = null;System.gc();Thread.sleep(1000);System.out.println('GC后獲取:' + weakReference.get());System.out.println('隊列中的結(jié)果:' + referenceQueue.poll());/** GC前獲取:java.lang.Object@61bbe9ba* GC后獲取:null* 隊列中的結(jié)果:java.lang.ref.WeakReference@610455d6* */break; case '虛引用':Object objPhan = new Object();PhantomReference<Object> phantomReference = new PhantomReference<>(objPhan, referenceQueue);System.out.println('GC前獲取:' + phantomReference.get());objPhan = null;System.gc();//此處的區(qū)別是當(dāng)objPhan的內(nèi)存被gc回收之前虛引用就會被加入到ReferenceQueue隊列中，其他的引用都為當(dāng)引用被gc掉時候，引用會加入到ReferenceQueue中Thread.sleep(1000);System.out.println('GC后獲取:' + phantomReference.get());System.out.println('隊列中的結(jié)果:' + referenceQueue.poll());/** GC前獲取:java.lang.Object@61bbe9ba* GC后獲取:null* 隊列中的結(jié)果:java.lang.ref.WeakReference@610455d6* */break;} }} Java GC

目前oracle jdk和open jdk的虛擬機(jī)都為Hotspot，android 為Dalvik和Art

曾經(jīng)的GC算法：引用計數(shù)

簡短的說引用計數(shù)就是對每一個對象的引用計算數(shù)字，如果引用就+1，不引用就-1，回收掉引用計數(shù)為0的對象。來達(dá)到垃圾回收

弊端：如果兩個對象都應(yīng)該被回收但是他倆卻互相依賴，那么他兩者的引用永遠(yuǎn)都不會為0，那么就永遠(yuǎn)無法回收， 無法解決循環(huán)引用的問題

這個算法只在很少數(shù)的虛擬機(jī)中使用過

現(xiàn)代的GC算法

標(biāo)記回收算法（Mark and Sweep GC） :從'GC Roots'集合開始，將內(nèi)存整個遍歷一次，保留所有可以被GC Roots直接或間接引用到的對象，而剩下的對象都當(dāng)作垃圾對待并回收，這個算法需要中斷進(jìn)程內(nèi)其它組件的執(zhí)行并且可能產(chǎn)生內(nèi)存碎片。 復(fù)制算法（Copying） :將現(xiàn)有的內(nèi)存空間分為兩快，每次只使用其中一塊，在垃圾回收時將正在使用的內(nèi)存中的存活對象復(fù)制到未被使用的內(nèi)存塊中，之后，清除正在使用的內(nèi)存塊中的所有對象，交換兩個內(nèi)存的角色，完成垃圾回收。 標(biāo)記-壓縮算法（Mark-Compact） :先需要從根節(jié)點開始對所有可達(dá)對象做一次標(biāo)記，但之后，它并不簡單地清理未標(biāo)記的對象，而是將所有的存活對象壓縮到內(nèi)存的一端。之后，清理邊界外所有的空間。這種方法既避免了碎片的產(chǎn)生，又不需要兩塊相同的內(nèi)存空間，因此，其性價比比較高。 分代 :將所有的新建對象都放入稱為年輕代的內(nèi)存區(qū)域，年輕代的特點是對象會很快回收，因此，在年輕代就選擇效率較高的復(fù)制算法。當(dāng)一個對象經(jīng)過幾次回收后依然存活，對象就會被放入稱為老生代的內(nèi)存空間。對于新生代適用于復(fù)制算法，而對于老年代則采取標(biāo)記-壓縮算法。

以上四種算法信息引用自QQ空間團(tuán)隊分享 Android GC 那點事 &version=11000003&pass_ticket=nhSGhYD4LC9FWvUPv26Y7AdIzqEDu8FTImf2AKlyrCk%3D) ，總結(jié)的特別棒

導(dǎo)致內(nèi)存泄漏的原因

對象在GC Root中可達(dá)，也就是他的引用不為空，所以GC無法回收它也就會導(dǎo)致內(nèi)存泄漏

GC Root起點

虛擬機(jī)棧中引用的對象 方法區(qū)中類靜態(tài)屬性引用的對象 方法區(qū)中常量引用的對象 JNI引用的對象 GC可以續(xù)一秒

當(dāng)一個對象在引用鏈中失S#x53BB;了引用，那么他就真的要告別世界了嗎，其實并不是，虛擬機(jī)會給他“緩刑”，每一個對象有一個finalize() 方法，虛擬機(jī)是否給他緩刑取決于這個對象的這個方法是否被執(zhí)行，如果這個對象的這個方法沒有被覆蓋或者這個方法被執(zhí)行過一次，那么就要“行刑”了。真的是“續(xù)一秒”

如果這個對象的finalize()方法應(yīng)該被執(zhí)行，那么虛擬機(jī)會將它放在F-Queue隊列中，稍后虛擬機(jī)會自動創(chuàng)建一個Finalizer線程去執(zhí)行這個隊列中的對象的這個方法。如果對象在finalize()中成功自救，舉個例子，把自己和一個存在的對象強(qiáng)引用，那么就不會被回收，否則就真的被回收了。

但是虛擬機(jī)并不會保證Finalizer線程執(zhí)行結(jié)束再進(jìn)行回收，因為如果在某一個對象的finalize()方法中執(zhí)行了死循環(huán)或者超級耗時的操作，虛擬機(jī)等待這個執(zhí)行結(jié)束的話就會導(dǎo)致整個Gc崩潰了

首先注意這個方法只能被執(zhí)行一次，第二次就會標(biāo)記了這個方法被執(zhí)行過不會再執(zhí)行了，其次，這個方法不一定會被執(zhí)行到，所以不要依賴finalize()去自救。這不是好的做法。

并發(fā)GC和非并發(fā)GC

Android2.3之后支持了并發(fā)的GC。

非并發(fā)GC : 虛擬機(jī)在執(zhí)行GC的時候進(jìn)行Stop the world，也就是掛起其他所有的線程，通常會持續(xù)上百毫秒，一次Mark，然后直接清理

并發(fā)GC : 跟非并發(fā)的簡單gc來比較，一般非并發(fā)GC需要耗費上百ms的時間來進(jìn)行，而并發(fā)gc僅僅需要10ms左右的時間，效率大幅度提升（數(shù)據(jù)來自：技術(shù)小黑屋大大），但是并發(fā)gc由于需要進(jìn)行重復(fù)的處理改動的對象，所以需要更多的CPU資源

兩者的差別：

首先非并發(fā)GC簡單粗暴，直接掛起所有的線程，此時Java堆中肯定不會有任何的添加和修改，此時去遞歸GC樹，然后標(biāo)記-清理。但是這樣會造成很大的開銷，大家都等著你豈不是很沒面子= =

然而非并發(fā)的GC是一點一點來的，跟線程同步進(jìn)行這樣就不會有很長時間的等待，但是你要明白一個道理，想把地掃干凈這段時間必須沒人來踩，所以他要有掛起線程的過程。

那么并發(fā)是怎么實現(xiàn)的呢？首先有個知識點就是Jvm在分配內(nèi)存的時候，有兩種方式

指針碰撞：一個指針，申請一塊內(nèi)存就指針挪動相應(yīng)的距離，不會產(chǎn)生內(nèi)存碎片，這要求內(nèi)存是很規(guī)整的 空閑列表：每次申請一塊內(nèi)存給需要的對象，然后有一個列表記錄了哪些位置被申請了，下次申請的時候就不申請這個位置，這樣適用于內(nèi)存不是很規(guī)整的情況

創(chuàng)建對象是一個頻繁的操作，那么我們?nèi)绾伪ＷC原子性呢？兩種方案

CAS(Compare and Swap)策略配上失敗重試來保證原子性 每個線程分配一個TLAB : 很簡單，每個線程自己有自己的一塊內(nèi)存，那么分配的時候自己鎖自己的分區(qū)就行了，提高了效率

我們用的是第二種 233

所以獲取Java堆鎖的時候，重點來了，我們逐個線程去鎖TLAB，而不是一次全鎖住，當(dāng)然提高了并發(fā)GC的效率，所以更快。但是引來的問題就是并發(fā)的問題，所以下一步要重復(fù)去修改在一個個探索時候被改的對象。也就需要更多的CPU資源。

我們?yōu)槭裁匆P(guān)注GC

首先我們知道虛擬機(jī)如何去GC才能了解到如何讓一個對象被正確的回收，這樣才不能內(nèi)存泄漏

其次無論是并發(fā)GC還是非并發(fā)GC都會導(dǎo)致掛起其他的所有線程，那么就會帶來程序卡頓。

ART在GC上做到了更加細(xì)粒度的控制，可以更加流暢的GC

常見的內(nèi)存泄漏案例:Handler內(nèi)存泄漏

首先鋪墊一句話：非靜態(tài)的內(nèi)部類和匿名類會隱式的持有外部類的引用

public class MainActivity extends AppCompatActivity { private Handler mHandler = new Handler() {@Overridepublic void handleMessage(Message msg) { Log.d('smallSohoSolo', 'Hello Handler');} }; @Override protected void onCreate(Bundle savedInstanceState) {super.onCreate(savedInstanceState);mHandler.postDelayed(new Runnable() { @Override public void run() {Log.d('smallSohoSolo', 'Running'); }}, 1000 * 60 * 10); //10分鐘之后執(zhí)行finish(); }}

這段代碼有很明顯的內(nèi)存泄漏，首先Handler和Runnable都是匿名內(nèi)部類的實例，他們都會持有MainActivity的引用，

Handler發(fā)送的消息到了消息隊列中 Activity被結(jié)束掉 這個消息中包含了Handler的引用，Handler包含了Activity的引用，而且他還是個Runnable，也是匿名內(nèi)部類，也間接包含了MainActivity引用 在Main Lopper中，當(dāng)此消息被取出來，這未執(zhí)行的10分鐘里面，MainActivity沒法回收 內(nèi)存泄漏

有人可能會說短暫的內(nèi)存泄漏又能怎樣？這是錯誤的想法，因為只要發(fā)生內(nèi)存泄漏，在這段時間只要進(jìn)行了大內(nèi)存的操作（比如加載一個照片墻），就有風(fēng)險因為這個內(nèi)存泄漏造成OOM（占用內(nèi)存肯定剩下的少了）

上面這個如何修改呢？

將Runnable和Handler改成static 或者在外部定義內(nèi)部使用。

其他常見的內(nèi)存泄漏 靜態(tài)變量內(nèi)存泄漏：使用靜態(tài)變量來引用一個事物，在不使用之后沒有下掉，那么引用存在就會一直泄漏 單例導(dǎo)致的內(nèi)存泄漏：使用的單例中保存了不應(yīng)該被一直持有的對象，那么就會造成內(nèi)存泄漏 由第三方庫使用不當(dāng)導(dǎo)致的內(nèi)存泄漏：比如EventBus，Activity銷毀的時候沒有反注冊就會導(dǎo)致引用一直被持有無法回收 還有很多。。。他們都是因為引用沒有被清理造成的 如何查看內(nèi)存泄漏

簡單粗暴 —> LeakCanary: Square出品的庫，當(dāng)出現(xiàn)內(nèi)存泄漏的時候會出現(xiàn)

精打細(xì)算 —> Android Studio 內(nèi)存工具: 可以Dump下來當(dāng)前的內(nèi)存路徑，然后分析出來哪些對象目前的狀態(tài)。很強(qiáng)

參考文獻(xiàn) 深入理解Java虛擬機(jī) Form: 周志明 Android GC那點事 &version=11000003&pass_ticket=nhSGhYD4LC9FWvUPv26Y7AdIzqEDu8FTImf2AKlyrCk%3D) Form: QQ空間終端團(tuán)隊 細(xì)話Java：'失效'的private修飾符 Form: 技術(shù)小黑屋 避免Android中Context引起的內(nèi)存泄露 Form: 技術(shù)小黑屋 Handler引起的內(nèi)存泄漏 Form: 技術(shù)小黑屋 Android 內(nèi)存泄漏案例和解析 Form: drakeet

來自：https://techblog.toutiao.com/2017/08/16/untitled-4/