一篇文章教会你---怎样理解Android内存泄漏以及如何分析

首先我们先谈谈java对象回收条件是什么?

当没有任何引用指向该对象的时候。
(存在两种情况：1.该对象的最后一个引用指向了另一个对象或null。 2.该对象的最后一个引用的作用域结束。)

内存泄漏是什么?

内存泄漏通俗来讲就是长生命周期对象强引用了短生命周期对象，在短生命周期对象想回收时，强生命周期还是不对其解除引用。这时候短生命周期对象就不会被回收，但我们的想法是以后不会用这个短生命周期对象了，这时候该对象就是泄漏的垃圾对象了。当这些对象泄漏的多了，就会占用大量内存，最终结果也就造成oom了。

下面我就用个简单的例子，来看看是不是这样的

public class Main2Activity extends AppCompatActivity {

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main2);
        Log.i("----------", "onCreate: activity_main2");
        new Thread(new Runnable() {
            @Override
            public void run() {
                for (int i = 0; i < 1000; i++) {
                    try {
                        Thread.sleep(3000);
                    } catch (InterruptedException e) {
                        e.printStackTrace();
                    }
                }
            }
        }).start();
    }
}

1.png

2.png

上面两张图我们很容易看出，我打开并退出了5次Main2Activity，然后用内存分析工具强制gc后Main2Activity实例数依然是5个，此时就是内存泄漏了。而内存泄漏的原因就是Thread对象持有了Runnable对象(和他持有Runnable关系不大)，Runnable对象中的run方法又间接持有了Main2Activity（这才是主要原因），然而这个Runnable对象中run方法短期又执行不完，结果就造成Runnable对象不会回收，Main2Activity也无法回收。

问题：此时Thread对象有没有回收?

答案:没有回收。
看下源码就知道原因了:

public class Thread implements Runnable {

    private Runnable target;

    @Override
    public void run() {
        if (target != null) {
            target.run();
        }
    }
}

我们可以看出Thread对象中也实现了Runnable接口，然后thread中run方法中调用了target.run();而这个target就是我们刚刚在Main2Activity中实现的Runnable对象。当我们开启一个线程之后，最终它会在那个线程中运行这个run方法，然而target.run执行结束前，thread的run方法肯定也结束不了了，就造成thread也无法回收(从另一个角度理解:thread中的run方法肯定也是持有thread对象的引用，所以这些方法执行完毕前这些被方法引用的对象也自然无法回收了)

最后再推荐一个很多人都知道的一个Android内存泄漏检查框架，leakcanary，我们也可以用他来检查内存泄漏。