文章简介
Android Handler的泄漏算是很有名了,Handler稍有不慎就会造成泄漏。上网一搜就能搜到一大堆解释的文章。但是,大部分其实都在翻译或者解释这篇著名的外文:
http://www.androiddesignpatterns.com/2013/01/inner-class-handler-memory-leak.html
这篇文章介绍了Handler发送的message以postDelayed的方式驻留在MessageQueue而引起内存泄漏的情况。
配合Handler-Looper-Message机制的理解,看完这篇文章,有一种恍然大悟的激动。
但是!
我们在写handler回发message的时候其实用postDelay的情况也不是占绝大部分,那是不是就不用处理泄漏的情况了呢?
我想啊想,于是想到 线程处理的延时 会不会造成泄漏呢,个人觉得是会的,但是希望求证一下,于是懒得不能自理的我开始在某度和G**gle上搜答案,搜了半天,可能因为上面那篇外文太酷炫,搜出的文章几乎全是讲的是外文中提及的情况。而且在这篇文章中
https://juejin.im/entry/58da161361ff4b0060716f02
作者提及handler泄漏的时候提及 * “只有postDelayed的时候才会有泄露问题,因为delayed的时候activity的引用还保持着,所以只要delayed完了就能回收了,大多数情况下根本不必用加static。” *
这一看我就怂了,因为自己感觉开匿名线程的情况还是挺多,如果线程泄漏的话handler的泄漏还是要处理一下的,可能作者并没有线程不会泄漏的意思,但我这云里雾里的,实在没办法,只好爬起来自己测试一番。于是,这篇文章诞生了。
文章会首先介绍外文提及的泄漏原理及测试,已经熟烂的兄弟姐妹可以直接跳过,后面会介绍线程与handler的配合导致泄漏的原理与测试结果, 大佬们肯定不用测试也心里有数,因此对java回收以及handler机制已经理解透彻的大佬默默地点一下网页右上角的叉叉就好了。
言归正传,本文使用的泄漏测试用的正是你们熟悉的LeakCanary 1.4,那么,现在开始。
Message驻留MessageQueue的泄漏情况
这种情况正是文章开头提到的那篇外文中提及的情况。来看一段代码
public class MainActivity extends AppCompatActivity {
private Handler handler = new Handler(){
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
private Thread leakThread;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
leakThread = new Thread(new LeakRunnable(handler));
leakThread.start();
Button button = (Button) findViewById(R.id.btn_start);
button.setOnClickListener(new View.OnClickListener() {
@Override
public void onClick(View v) {
SecondActivity.StartSecondActivity(MainActivity.this);
finish();
}
});
}
}
这段代码相当简单,只有三个点
- 有一个内部匿名Handler类。
- 有一个私有线程成员,leakThread,线程的runnable来自Runnable实现类 LeakRunnable(代码后面贴出,也很简单),并且这个Runnable注入了handler,内部持有handler这个引用。
- 有一个button,点击会跳转到别的activity并finish(),这样的话,在正常情况下garbage collector就会在合适的时候回收MainActivity对象。
好,代码看完了,首先明确一点: java的内部类会默认持有外部类的对象引用。在这段代码的表现就是handler会持有MainActivity这个对象的引用。
然后要知道这段代码有两条关键的引用链,
第一条,从这段代码就能看出来的:
mainActivity -(1.1)-> leakThread -(1.2)-> handler -(1.3)-> mainActivity
第二条,从Handler->Looper->MessageQueue机制看出来的:
sMainLooper-(2.1)->mMessageQueue-(2.2)->mMessage-(2.3)->handler-(2.4)->mainActivity
解释一下第二条链是怎么出现的:
主线程拥有一个Looper叫sMainLooper,这个Looper是静态变量,与程序共存亡,而Looper中持有一个MessageQueue的对象,可以看Looper的源码(只贴出了一小部分),里面有个mQueue的成员变量
public final class Looper {
/*
* API Implementation Note:
*
* This class contains the code required to set up and manage an event loop
* based on MessageQueue. APIs that affect the state of the queue should be
* defined on MessageQueue or Handler rather than on Looper itself. For example,
* idle handlers and sync barriers are defined on the queue whereas preparing the
* thread, looping, and quitting are defined on the looper.
*/
private static final String TAG = "Looper";
// sThreadLocal.get() will return null unless you've called prepare().
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
private static Looper sMainLooper; // guarded by Looper.class
final MessageQueue mQueue;
}
MessageQueue中持有message对象,同样,源码中有个mMessage的对象
public final class MessageQueue {
private static final String TAG = "MessageQueue";
Message mMessages;
}
Message中持有Handler对象, 在handler发送消息时会把持有的handler引用指向发送自己的handler,在源码中这个对象名叫target, 代码就不贴出来啦。
因此出现了上面所说的引用链。
当LeakRunnable的实现是如下图所示的时候,handler发送一个10分钟延迟的消息,造成的就是经典的message驻留在messageQueue引起泄漏的情况。
public class LeakRunnable implements Runnable {
private Handler handler;
private Message msg;
public LeakRunnable(Handler handler){
this.handler = handler;
msg = new Message();
}
@Override
public void run() {
MessageQueue_Message_Leak();
}
public void MessageQueue_Message_Leak(){
msg.what = 0;
handler.sendMessageDelayed(msg,1000 * 60 * 10);
}
}
我们可以从代码很容易分析到,当activity需要被回收时,由于message需要在MessageQueue中驻留10分钟,此时第二条引用链无法断开,使得本应该被回收的mainActivity被强引用持有而无法回收。分析到这里,我们运行程序点击start,等几秒就会收到LeakCanary的推送了,看图!
结果正如分析所提到的一样,引用链的(2.2),(2.3),(2.4)节点都出现在了推送上。
这种泄漏情况就分析到这就结束了,还不懂的可以看看链接的外文,文章写得相当清楚,下面进入下一章,分析一个使用handler更新ui的线程在处理耗时操作造成的泄漏情况。
带有耗时操作的线程通过handler更新UI造成泄漏的情况
首先把上一章的引用链再贴一遍,这一章要用到
mainActivity -(1.1)-> leakThread -(1.2)-> handler -(1.3)-> mainActivity
sMainLooper-(2.1)->mMessageQueue-(2.2)->mMessage-(2.3)->handler-(2.4)->mainActivity
测试主界面依然跟上一章一样,不同的是LeakRunnable的run逻辑。
public class LeakRunnable implements Runnable {
private Handler handler;
private Message msg;
public LeakRunnable(Handler handler){
this.handler = handler;
msg = new Message();
}
@Override
public void run() {
Thread_Handler_Leak();
}
public void Thread_Handler_Leak(){
while(true){
try {
Thread.sleep(1000 * 10 * 60);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
这次runnable里面甚至没有使用handler发送消息,仅仅是把主线程的handler注入进来,并且run方法模拟了一个耗时操作。由于没有发送消息,这下跟什么Message,MessageQueue没关系了,也就是(2.2),(2.3)节点断开了。那不会泄漏了吧?
答案当然是否定的。为什么?因为我还没提到过第一条引用链呀。
当handler不发送message的时候第一条引用链还是存在的,试想,如果耗时操作存在,节点(1.2)(1.3)是会长时间存在的。
但聪明的你一定会问:那(1.1)呢?!
没错,(1.1)的存在表明了mainActivity跟leakThread对象的关系有点像循环引用,只是多了个handler作为中间者来桥接,而handler的生命周期在这种情况下完全是依赖于thread或者mainAcitivity的,因此handler对分析泄漏过程不起关键作用。按照现代java gc来说,什么循环引用都是渣渣,我们有可达性算法,标记清除法,不会泄漏!
(关于java垃圾回收这方面不熟悉的可以看看这个
http://www.cnblogs.com/sunniest/p/4575144.html)
那么,真的不会泄漏吗?
点击一下界面的start,现在看看LeakCanary的推送:
好的,泄漏了。泄漏的正是第一条引用链的整条链。
为什么?因为可达性分析算法依赖定义的GC Root对象,参考java文档
https://www.yourkit.com/docs/java/help/gc_roots.jsp
可知道live Thread是被jvm识别为GC Root的,因此只要leakThread活着,即使activity生命周期已经结束,可达性分析算法会觉得第一条链中整条链的对象均不应该被回收,泄漏就会发生。
这种泄漏应该引起我们注意,因为我们经常都会传入一个handler引用到子线程来通知activity更新ui,而子线程往往都有耗时任务要处理,因此我们写代码的时候很容易就在不知不觉中操作到了内存泄漏的handler。
至于怎么解决?断开引用链呗。怎么断?方法多的是
- 比如使用弱引用来引用传进来的handler,这样(1.2)节点就会断开(但这样做需要注意在通知ui更新时对handler的引用判空,不然你的老朋友NullPointException一定会来光顾的,为什么?都有耐心看到这来,你就结合上面说的思考一下呗)。
public class LeakRunnable implements Runnable {
private WeakReference<Handler> handler;
private Message msg;
public LeakRunnable(Handler handler){
this.handler = new WeakReference<Handler>(handler);
msg = new Message();
}
@Override
public void run() {
Thread_Handler_Leak();
}
public void Thread_Handler_Leak(){
while(true){
try {
Thread.sleep(1000 * 60 * 10 );
if(handler.get() != null) {
handler.get().sendEmptyMessage(0);
}
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
Handler定义为静态内部类,这样做handler就不会持有mainActivity的引用。但这样的话就不方便我们更新ui。因此可以同样地传一个mainActivity的弱引用进去。
在mainActivity destroy的时候停止线程的工作并回收线程资源。
解决方法我只提供了思路,就不细讲了,各位老铁那么聪明,思考一下肯定就实现了。到这里测试与分析就结束啦。