小題大做 | Handler內存泄露全面分析

前言

嗨，大家好，問大家一個“簡單”的問題：

Handler內存泄露的原因是什么？

你會怎么答呢？

這是錯誤的回答

有的朋友看到這個題表示，就這？太簡單了吧。

"內部類持有了外部類的引用，也就是Hanlder持有了Activity的引用，從而導致無法被回收唄。"

其實這樣回答是錯誤的，或者說沒回答到點子上。

內存泄漏

Java虛擬機中使用可達性分析的算法來決定對象是否可以被回收。即通過GCRoot對象為起始點，向下搜索走過的路徑（引用鏈），如果發現某個對象或者對象組為不可達狀態，則將其進行回收。

而內存泄漏指的就是有些對象（短周期對象）沒有用了，但是卻被其他有用的類（長周期對象）所引用，從而導致無用對象占據了內存空間，形成內存泄漏。

所以上面的問題，如果僅僅回答內部類持有了外部類的引用，沒有指出內部類被誰所引用，那么按道理來說是不會發生內存泄漏的，因為內部類和外部類都是無用對象了，是可以被正常回收的。

所以這一題的關鍵在於，內部類被誰引用了？也就是Handler被誰引用了？

一起通過實踐研究下吧～

Handler發生內存泄漏的情況

1、發送延遲消息

第一種情況，是通過handler發送延遲消息：

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_handler)

        btn.setOnClickListener {
        	//跳轉到HandlerActivity
            startActivity(Intent(this, HandlerActivity::class.java))
        }
    }
}

class HandlerActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_handler2)

        //發送延遲消息
        mHandler.sendEmptyMessageDelayed(0, 20000)

        btn2.setOnClickListener {
            finish()
        }
    }

    val mHandler = object : Handler() {
        override fun handleMessage(msg: Message?) {
            super.handleMessage(msg)
            btn2.setText("2222")
        }
    }
}

我們在HandlerActivity中，發送一個延遲20s的消息。然后打開HandlerActivity后，馬上finish。看看會不會內存泄漏。

查看內存泄漏並分析

現在查看內存泄漏還是蠻方便的了，AndroidStudio自帶對堆轉儲（Heap Dump）文件進行分析，並且會把內存泄漏點明確標出來。

我們運行項目，點擊Profiler——Memory，就能看到以下圖片了，一個正在運行的內存情況實時圖：

可以看到圖片中有兩個按鈕我標出來了：

• 捕獲堆轉儲文件按鈕，也就是生成hprof文件，這個文件會展示Java堆的使用情況，點擊這個按鈕后，AndroidStudio會幫我們生成這個堆轉儲文件並且進行分析。
• GC按鈕，一般我們在我們捕獲堆轉儲文件之前，點一下GC，就能把一些弱引用給回收，防止給我們分析帶來干擾。

所以我們打開HandlerActivity后，馬上finish，然后點擊GC按鈕，再點擊捕獲堆轉儲文件按鈕。AndroidStudio會自動跳轉到以下界面：

可以看到左上角有一個Leaks，這就是你內存泄漏的點，點擊就能看到內存泄漏的類了。右下角就是內存泄漏類的引用路徑。

從這張圖可以看到，我們的HandlerActivity發生了內存泄漏，從引用路徑來看，是被匿名內部類的實例mHandler持有引用了，而Handler的引用是被Message持有了，Message引用是被MessageQueue持有了...

結合我們所學的Handler知識和這次引用路徑分析，這次內存泄漏完整的引用鏈應該是：

主線程 —> threadlocal —> Looper —> MessageQueue —> Message —> Handler —> Activity

所以這次引用的頭頭就是主線程，主線程肯定是不會被回收的，只要是運行中的線程都不會被JVM回收，跟靜態變量一樣被JVM特殊照顧。

這次內存泄漏的原因算是搞清楚了，當然Handler內存泄漏的情況不光這一種，看看第二種情況：

2、子線程運行沒結束

第二個實例，是我們常用到的，在子線程中工作，比如請求網絡，然后請求成功后通過Handler進行UI更新。

class HandlerActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContentView(R.layout.activity_handler2)

        //運行中的子線程
        thread {
            Thread.sleep(20000)
            mHandler.sendEmptyMessage(0)
        }

        btn2.setOnClickListener {
            finish()
        }
    }

    val mHandler = object : Handler() {
        override fun handleMessage(msg: Message?) {
            super.handleMessage(msg)
            btn2.setText("2222")
        }
    }
}

同樣運行后看看內存泄漏情況：

可以發現，這里的內存泄漏主要的原因是因為這個運行中的子線程，由於子線程這個匿名內部類持有了外部類的引用，而子線程本身是一直在運行的，剛才說過運行中的線程是不會被回收的，所以這里內存泄漏的引用鏈應該是：

運行中的子線程 —> Activity

當然，這里的Handler也是持有了Activity的引用的，但主要引起內存泄漏的原因還是在於子線程本身，就算子線程中不用Handler，而是調用Activity的其他變量或者方法還是會發生內存泄漏。

所以這種情況我覺得不能看作Handler引起內存泄漏的情況，其根本原因是因為子線程引起的，如果解決了子線程的內存泄漏，比如在Activity銷毀的時候停止子線程，那么Activity就能正常被回收，那么也不存在Handler的問題了。

延伸問題1:內部類為什么會持有外部類的引用

這是因為內部類雖然和外部類寫在同一個文件中，但是編譯后還是會生成不同的class文件，其中內部類的構造函數中會傳入外部類的實例，然后就可以通過this$0訪問外部類的成員。

其實也挺好理解的吧，因為在內部類中可以調用外部類的方法，變量等等，所以肯定會持有外部類的引用的。

貼一段內部類在編譯后用JD-GUI查看的class代碼，也許你能更好的理解：

//原代碼
class InnerClassOutClass{

    class InnerUser {
       private int age = 20;
    }
}

//class代碼
class InnerClassOutClass$InnerUser {
    private int age;
    InnerClassOutClass$InnerUser(InnerClassOutClass var1) {
        this.this$0 = var1;
        this.age = 20;
     }
}

延伸問題2:kotlin中的內部類與Java有什么不一樣嗎

其實可以看到，在上述的代碼中，我都加了一句

btn2.setText("2222")

這是因為在kotlin中的匿名內部類分為兩種情況：

• 在Kotlin中，匿名內部類如果沒有使用到外部類的對象引用時候，是不會持有外部類的對象引用的，此時的匿名內部類其實就是個靜態匿名內部類，也就不會發生內存泄漏。
• 在Kotlin中，匿名內部類如果使用了對外部類的引用，像我剛才使用了btn2，這時候就會持有外部類的引用了，就會需要考慮內存泄漏的問題。

所以我特意加了這一句，讓匿名內部類持有外部類的引用，復現內存泄漏問題。

同樣kotlin中對於內部類也是和Java有區別的：

• Kotlin中所有的內部類都是默認靜態的，也就都是靜態內部類。
• 如果需要調用外部的對象方法，就需要用inner修飾，改成和Java一樣的內部類，並且會持有外部類的引用，需要考慮內存泄漏問題。

解決內存泄漏

說了這么多，那么該怎么解決內存泄漏問題呢？其實所有內存泄漏的解決辦法都大同小異，主要有以下幾種：

• 不要讓長生命周期對象持有短生命周期對象的引用，而是用長生命周期對象持有長生命周期對象的引用。

比如單例模式不要傳入Activity上下文。

• 將對象的強引用改成弱引用

強引用就是對象被強引用后，無論如何都不會被回收。
弱引用就是在垃圾回收時，如果這個對象只被弱引用關聯（沒有任何強引用關聯他），那么這個對象就會被回收。
軟引用就是在系統將發生內存溢出的時候，回進行回收。
虛引用是對象完全不會對其生存時間構成影響，也無法通過虛引用來獲取對象實例，用的比較少。

所以我們將對象改成弱引用，就能保證在垃圾回收時被正常回收，比如Handler中傳入Activity的弱引用實例：

    MyHandler(WeakReference(this)).sendEmptyMessageDelayed(0, 20000)

    //kotlin中內部類默認為靜態內部類
    class MyHandler(var mActivity: WeakReference<HandlerActivity>):Handler(){
        override fun handleMessage(msg: Message?) {
            super.handleMessage(msg)
            mActivity.get()?.changeBtn()
        }
    }

• 內部類寫成靜態類或者外部類

跟上面Hanlder情況一樣，有時候內部類被不正當使用，容易發生內存泄漏，解決辦法就是寫成外部類或者靜態內部類。

• 在短周期結束的時候將可能發生內存泄漏的地方移除

比如Handler延遲消息，資源沒關閉，集合沒清理等等引起的內存泄漏，只要在Activity關閉的時候進行消除即可：

@Override
protected void onDestroy() {
　　//移除handler所有消息
　　if(mHanlder != null){
		mHandler.removeCallbacksAndMessages(null)
　　}
　　super.onDestroy();
}

總結

Handler內存泄露的原因是什么？

Handler導致內存泄漏一般發生在發送延遲消息的時候，當Activity關閉之后，延遲消息還沒發出，那么主線程中的MessageQueue就會持有這個消息的引用，而這個消息是持有Handler的引用，而handler作為匿名內部類持有了Activity的引用，所以就有了以下的一條引用鏈。

主線程 —> threadlocal —> Looper —> MessageQueue —> Message —> Handler —> Activity

其根本原因是因為這條引用鏈的頭頭，也就是主線程，是不會被回收的，所以導致Activity無法被回收，出現內存泄漏，其中Handler只能算是導火索。

而我們平時用到的子線程通過Handler更新UI，其原因是因為運行中的子線程不會被回收，而子線程持有了Actiivty的引用（不然也無法調用Activity的Handler），所以就導致內存泄漏了，但是這個情況的主要原因還是在於子線程本身。

所以綜合兩種情況，在發生內存泄漏的情況中，Handler都不能算是罪魁禍首，罪魁禍首（根本原因）都是他們的頭頭——線程。

參考

Handler 內存泄露
引用介紹
Kotlin 內存泄漏

拜拜

有一起學習的小伙伴可以關注下❤️ 我的公眾號——碼上積木，每天剖析一個知識點，我們一起積累知識。公眾號回復111可獲得面試題《思考與解答》以往期刊。