系统相关
首页 > 系统相关> > 一次性讲清楚 Handler 可能导致的内存泄漏和解决办法

一次性讲清楚 Handler 可能导致的内存泄漏和解决办法

作者:互联网

作者:小虾米君

1. Handler 使用不当?

先搞清楚什么叫 Handler 使用不当?

一般具备这么几个特征:

  1. Handler 采用匿名内部类内部类扩展,默认持有外部类 Activity 的引用:
// 匿名内部类
override fun onCreate(savedInstanceState: Bundle?) {
    ...
    val innerHandler: Handler = object : Handler(Looper.getMainLooper()) {
        override fun handleMessage(msg: Message) {
            Log.d(
                "MainActivity",
                "Anonymous inner handler message occurred & what:${msg.what}"
            )
        }
    }
}

// 内部类
override fun onCreate(savedInstanceState: Bundle?) {
    ...
    val innerHandler: Handler = MyHandler(Looper.getMainLooper())
}

inner class MyHandler(looper: Looper): Handler(looper) {
    override fun handleMessage(msg: Message) {
        Log.d(
            "MainActivity",
            "Inner handler message occurred & what:\${msg.what}"
        )
    }
}
  1. Activity 退出的时候 Handler 仍可达,有两种情况:
override fun onCreate(savedInstanceState: Bundle?) {
    ...
    val elseThread: Thread = object : Thread() {
        override fun run() {
            Log.d(
                "MainActivity",
                "Thread run"
            )
            
            sleep(2000L)
            innerHandler.sendEmptyMessage(1)
        }
    }.apply { start() }
}

2. 为什么会内存泄露?

上述的 Thread 在执行的过程中,如果 Activity 进入了后台,后续因为内存不足触发了destroy。虚拟机在标记 GC 对象的时候,会发生如下两种情形:

public final class Looper {
    private static Looper sMainLooper;  // guarded by Looper.class
    ...
    public static void prepareMainLooper() {
        prepare(false);
        synchronized (Looper.class) {
            sMainLooper = myLooper();
        }
    }
}

静态属性也是 GC Root 对象,其通过上述的应用链导致 Activity 仍然可达。

这两种情形都将导致 Activity 实例将无法被正确地标记,直到 Thread 结束 且 Message 被处理完毕。在此之前 Activity 实例将得不到回收。

内部类 Thread 也会导致 Activity 无法回收吧?

为了侧重阐述 Handler 导致的内存泄漏,并没有针对 Thread 直接产生的引用链作说明。

上面的代码示例中 Thread 也采用了匿名内部类形式,其当然也持有 Activity 实例。从这点上来说,尚未结束的 Thread 会直接占据 Acitvity 实例,这也是导致 Activity 内存泄露的一条引用链,需要留意!

3. 子线程 Looper 会导致内存泄露吗?

为了便于每个线程方便拿到独有的 Looper 实例,Looper 类采用静态的 sThreadLocal属性管理着各实例。

public final class Looper {
    static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
    ...
    public static @Nullable Looper myLooper() {
        return sThreadLocal.get();
    }
}

可是作为静态属性的话,sThreadLocal 也是 GC Root 对象。那从这个角度讲会不会也间接导致 Message 无法回收呢?

会,但本质上不是因为 ThreadLocal,而是因为 Thread。

翻看 ThreadLocal 的源码,你会发现:目标对象并不存放在 ThreadLocal 中,而是其静态内部类 ThreadLocalMap 中。加上为了线程独有,该 Map 又被 Thread 持有,两者的生命周期等同

// TheadLocal.java
public class ThreadLocal<T> {
    public void set(T value) {
        Thread t = Thread.currentThread();
        ThreadLocalMap map = getMap(t);
        if (map != null)
            map.set(this, value);
        else
            createMap(t, value);
    }

    // 创建 Map 并放到了 Thread 中
    void createMap(Thread t, T firstValue) {
        t.threadLocals = new ThreadLocalMap(this, firstValue);
    }
    
    ThreadLocalMap getMap(Thread t) {
        return t.threadLocals;
    }
}

// Thread.java
public class Thread implements Runnable {
    ThreadLocal.ThreadLocalMap threadLocals = null;
}

更进一步的细节是:ThreadLocalMap 中的元素 Entry 采用弱引用持有作为 key 的 ThreadLocal 对象,但作为 value 的目标对象则被强引用着的。

这就导致 Thread 间接持有着目标对象,比如本次的 Looper 实例。这样可以确保 Looper 的生命周期和 Thread 保持一致,但 Looper 生命周期过长会有内存泄漏的风险(当然这不是 Looper 设计者的锅)。

// TheadLocal.java
public class ThreadLocal<T> {
    ...
    static class ThreadLocalMap {
        private Entry[] table;

        static class Entry extends WeakReference<ThreadLocal<?>> {
            /** The value associated with this ThreadLocal. */
            Object value;

            Entry(ThreadLocal<?> k, Object v) {
                super(k);
                value = v;
            }
        }
    }
}

当弱引用的 key 实例因为 GC 发生会被切断和 Map 的引用关系,但直到下一次手动执行 Entry 的 setget 或 remove 前,value 都没被置为 null。这段时间 value 都被强引用着,造成隐患。

The entries in this hash map extend WeakReference, using its main ref field as the key (which is always a ThreadLocal object).

Note that null keys (i.e. entry.get() == null) mean that the key is no longer referenced, so the entry can be expunged from table.

Such entries are referred to as “stale entries” in the code that follows.

但需要注意的是:本处 Looper 持有的实例 sThreadLocal 是静态的,进程结束之前都不会被回收,不可能发生上述提及的 key 被回收 value 被孤立的情况

简言之,Looper 的 ThreadLocal 不会导致内存泄漏。

回到 Thread,因其强引用 Looper,所以 Thread 仍然会因为这个因素导致 Message 发生内存泄漏。 比如:向子线程 Handler 发送了内部类写法的 Runnable,当 Activity 结束的时候该 Runnable 尚未抵达或正在执行过程中,那么 Activity 会因为如下的引用链一直可达,即发生内存泄漏的可能。

解决办法不复杂:

最后,明确几点共识:

  1. 管理 Looper 实例的静态属性 sThreadLocal,并不持有实际存放 Looper 的 ThreadLocalMap,而是通过 Thread 去读写 。这使得 sThreadLocal 虽贵为  GC Root,但无法达成到 Looper 的引用链,进而从这条路径上并不能构成内存泄漏!

  2. 另外,因其是静态属性,也不会发生 key 被回收 value 被孤立的内存泄漏风险~

  3. 最后,由于 Thread 持有 Looper value,从这条路径上来说是存在内存泄漏的可能的

4. 非内部类的 Handler 会内存泄露吗?

上面说过匿名内部类或内部类是 Handler 造成内存泄漏的一个特征,那如果 Handler 不采用内部类的写法,会造成泄露吗?

比如这样:

override fun onCreate(...) {
    Handler(Looper.getMainLooper()).apply {
        object : Thread() {
            override fun run() {
                sleep(2000L)
                post { 
                    // Update ui
                }
            }
        }.apply { start() }
    }
}

仍然可能造成内存泄漏。

虽然 Handler 不是内部类,但 post 的 Runnable 也是内部类,其同样会持有 Activity 的实例。另外,post 到 Handler 的 Runnable 最终会作为 callback 属性被 Message 持有。

基于这两个表现,即便 Handler 不是内部类了,但因为 Runnable 是内部类,同样会发生 Activity 被 Thread 或 Main Looper 不当持有的风险。

5. 网传的 Callback 接口真得能解决吗?

网上有种说法:创建 Handler 时不覆写 handleMessage(),而是指定 Callback 接口实例,这样子可以避免内存泄漏。理由是这种写法之后 AndroidStudio 就不会再弹出如下的警告:

This Handler class should be static or leaks might occur.

事实上,Callback 实例如果仍然是匿名内部类或内部类的写法,仍然会造成内存泄漏,只是 AS 没弹出这层警告而已。

private Handler mHandler = new Handler(new Handler.Callback() {
    @Override  
    public boolean handleMessage(Message msg) {  
        return false;  
    }  
}); 

比如上面的这种写法,Handler 会持有传递进去的 Callback 实例,而 Callback 作为内部类写法,默认持有外部类 Activity 的引用。

public class Handler {
    final Callback mCallback;

 public Handler(@NonNull Looper looper, @Nullable Callback callback) {
        this(looper, callback, false);
    }

    public Handler(@NonNull Looper looper, @Nullable Callback callback, boolean async) {
        ...
        mCallback = callback;
    }
}

无论是从 Thread 活跃的角度,还是从 Thread 结束但 Message 仍然未执行完的角度来说,都将导致 Activity 仍然可被 GC Root 间接引用而发生内存泄漏的风险。

本质来说和上面的 Runnable 例子是一样的问题:

6. 正确使用 Handler?

GC 标记的时候 Thread 已结束并且 Message 已被处理的条件一旦没有满足,Activity 的生命周期就将被错误地延长,继而引发内存泄露!

那如何避免这种情况的发生呢?针对上面的特征,其实应该已经有了答案:

代码示例简述如下:

  1. 将 Handler 或 Callback 或 Runnable 定义为静态内部类
class MainActivity : AppCompatActivity() {
    private class MainHandler(looper: Looper?, referencedObject: MainActivity?) :
            WeakReferenceHandler<MainActivity?>(looper, referencedObject) {
        override fun handleMessage(msg: Message) {
            val activity: MainActivity? = referencedObject
            if (activity != null) {
                // ...
            }
        }
    }
}
  1. 还需要弱引用外部类的实例:
open class WeakReferenceHandler<T>(looper: Looper?, referencedObject: T) :     Handler(looper!!) {
    private val mReference: WeakReference<T> = WeakReference(referencedObject)

    protected val referencedObject: T?
        protected get() = mReference.get()
}
  1. onDestroy 的时候切断引用链关系,纠正生命周期:
override fun onDestroy() {
    ...
    thread.interrupt()
}

如果子线程中创建了 Looper 并成为了 Looper 线程的话,须手动 quit。比如 HandlerThread

override fun onDestroy() {
    ...
    handlerThread.quitSafely()
}
override fun onDestroy() {
    ...
    mainHandler.removeCallbacksAndMessages(null)
}

※1:Message 在执行 recycle() 后会清除其与和 Main Handler 的引用关系

※2:Looper 子线程调用 quit 时会清空 Message,所以无需针对子线程的 Handler 再作 Message 的清空处理了

结语

回顾一下本文的几个要点:

简单来讲的正确做法:

  1. 使用 Handler 机制的时候,无论是覆写 Handler 的 handleMessage() 方式,还是指定回调的 Callback 方式,以及发送任务的 Runnable 方式,尽量采用静态内部类 + 弱引用,避免其强引用持有 Activity 的实例。

确保即便错误地延长了生命周期,Activity 也能及时被 GC 回收

  1. 同时在 Activity 结束的时候,及时地清空 Message、终止 Thread 或退出 Looper,以便回收 Thread 或 Message。

确保能彻底切断 GC Root 抵达 Activity 的引用链

标签:讲清楚,实例,Thread,Handler,内存,Activity,Message,Looper
来源: https://blog.csdn.net/u012165769/article/details/122322618