最近一直在学习JVM内存分配回收相关的知识，看了那么多东西，终归还是要回到项目，回到代码中来。
今天就和大家聊一下内存泄漏的问题，我相信进入中高级开发的同学对这个问题都不陌生，甚至很多人觉得这个问题so easy，不就是常见的那几个吗，有什么高深的东西呢？这里先不争论。
你是如何定义内存泄漏的？
很多同学可能看过网上各种说法，我们先且不看这些，先来看一下百科的定义：
内存泄漏（Memory Leak）是指程序中己动态分配的堆内存由于某种原因程序未释放或无法释放，造成系统内存的浪费，导致程序运行速度减慢甚至系统崩溃等严重后果。
百科的观点，我基本认同，泄漏的本质却是是程序运行时分配出去的内存没有及时回收，导致内存空间越来越小，直到最后OOM。注意：我这里说的是基本认同，实际上不仅仅是堆内存会泄漏，实际上虚拟机栈、本地方法栈、方法区也都有可能会内存泄漏和oom，只是平时在app开发中内存泄漏和GC回收的主要区域是堆内存，它也是运行时内存比较大的一块内存。
上面说了，内存没有及时回收才导致的泄漏，那为什么会导致创建对象时分配的内存回收不了呢？
这主要和GC垃圾回收机制有关，其中关键的流程有2步：
- 1、标记哪些对象是可回收的（可达性算法GcRoot）；
- 2、回收内存空间。
可达性分析算法GcRoot大致意思如下：
先找到一系列“GC Roots”的对象作为起始点，从这个节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain）,当一个对象到GC Roots没有任何引用链相连时，说明这个对象是可回收的。
哪些对象可以作为GcRoot?大致有这么几种
- 虚拟机栈（栈帧中的本地变量表）中引用的对象
- 本地方法栈中JNI（即一般说的Native方法）引用的对象
- 方法区中类静态属性引用的对象
- 方法区中常量引用的对象
下面说一下常见的案例分析：
今天先说一下最典型的2个，内部类／匿名内部类、Handler的内存泄漏，其它的后面有时间再补充。
内部类／匿名内部类
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new InnerClass()).start();
}
class InnerClass implements Runnable {
@Override
public void run() {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
}
这段代码，当Activity退出时，如果Thread线程还有正在进行的任务就会发生内存泄漏。下面先来分析一下为什么会泄漏？
很多人都听说过非静态内部类／匿名内部类会持有外部类的引用。可你知道是为什么吗？其实也不复杂，如果你创建一个包含内部类／匿名内部类的java文件，然后通过javac编译成class文件，你会发现，这些内部类／匿名内部类会被编译成一个单独的class文件，并且它的构造方法中会传入外部类对象。
上面的MainActivity就会被编译成：
#InnerClass
class MainActivity$InnerClass implements Runnable {
/* synthetic */ MainActivity this$0;
MainActivity$InnerClass(MainActivity mainActivity) {
this.this$0 = mainActivity;
}
public void run() {
try {
Thread.sleep(10000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
public class MainActivity extends AppCompatActivity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
new Thread(new MainActivity$InnerClass()).start();
}
}
这其实是编译器的语法糖，匿名内部类也是差不多的，你可以自己尝试。
回到刚才的问题，为什么MainActivity会泄漏呢？因为Activity退出的时候，InnerClass还没有被回收，就导致Activity也不能回收，所以就泄漏了。
那为什么Activity退出了，InnerClass还不能被回收呢？
看一下创建／执行Thread的地方。JVM中，Thread是直接被GC Root所引用在JVM中，所以运行的线程是不会被回收的。在Activity退出之后，Thread对象是不会被回收的，它持有的这个InnerClass就不会被回收，而InnerClass又持有MainActivity引用，所以就泄漏了。
GcRoot引用链如下：
解决方案
既然现在已经知道内部类引发的内存泄漏是由于Activity对象存在一条可到达GcRoot的引用链造成的，那只要把引用关系1或者2断开就可以解决问题了。
方案1:
在退出Activity之前关闭线程，注意：用interrupt比stop更加可靠。这样的话，当Activity退出时，由于Thread处于非活跃状态，Thread和Activity都可以回收，这是针对引用1的解决方案。
@Override
protected void onDestroy() {
super.onDestroy();
thread.interrupt();
}
方案2:
把InnerClass这个内部类变成静态内部类，这样的话就不再持有外部类Activity的引用，这是针对引用2的解决方案。
小知识
非静态内部类和静态内部类在编译成class的时候都会生成单独的class文件，2者比较大的区别在于：编译之后的class中，非静态内部类的构造参数会传入外部类对象，也就是说非静态内部类持有外部类引用；而静态内部类不传入外部类对象，也就不持有传入外部类引用。
Handler泄漏
public class HandlerActivity extends AppCompatActivity {
private Handler handler = new Handler() {
@Override
public void handleMessage(Message msg) {
super.handleMessage(msg);
}
};
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_handler);
handler.sendEmptyMessageDelayed(0,10000);
}
}
这段代码，大家也很熟悉，通过匿名内部类的方式创建Handler，如果退出Activity的时候，消息队列中还有未处理的消息，那么Handler和Activity就会发生内存泄漏。
泄漏剖析：
这里通过匿名内部类的方式创建的Handler，从案例1的解析可以知道，匿名内部类也是隐式持有外部类的引用，所以Activity没办法被回收是因为Handler没有被回收，handler又持有Activity的引用。那为什么Handler不被回收呢？
发送消息时，是通过sendEmptyMessageDelayed去完成的，通过追踪这个方法内部的源码可以知道，最后会执行到如下方法
#Handler.java
private boolean enqueueMessage(MessageQueue queue, Message msg, long uptimeMillis) {
msg.target = this; //1
if (mAsynchronous) {
msg.setAsynchronous(true);
}
return queue.enqueueMessage(msg, uptimeMillis);
}
在代码1处的target实际上是Message类中的成员变量，它的类型是Handler，这里的target实际上就是当前Handler对象。这里可以看出Message对象持有了Handler对象的引用。如果你看过Handler源码的话，你会知道，Handler是在主线程创建了一个Looper对象，循环的从消息队列中中取消息／处理消息，如果你退出页面的时候，在消息队列中还有Message存在，这个Message被MessageQueue所引用，MessageQueue又被Looper引用，在Looper中有这么个属性sThreadLocal,它是static变量，他可以作为gcroot的
static final ThreadLocal<Looper> sThreadLocal = new ThreadLocal<Looper>();
所以handler发生泄漏的引用链为
threadLocal->Looper-> MessageQueue->Message->Handler->Activity
分析到这里，要想解决问题就很容易了，要想不泄漏，只需要在退出时断开Message--->Handler的引用即可。要想解决这个问题，需要看一下Handler源码，在Handler源码中，可以看到Looper的loop()方法是循环处理消息的，在消息处理完之后，会调用如下方法来回收
#Looper.loop
msg.recycleUnchecked();
#Message
void recycleUnchecked() {
// Mark the message as in use while it remains in the recycled object pool.
// Clear out all other details.
flags = FLAG_IN_USE;
what = 0;
arg1 = 0;
arg2 = 0;
obj = null;
replyTo = null;
sendingUid = -1;
when = 0;
target = null; //handler置空
callback = null;
data = null;
}
这里通过target = null;让Message和Handler的引用断开，这样的话Activity和Handler就可以回收了。
解决方案
方案1:
通过handler的removeCallbacksAndMessages()方法可以清空消息队列，它里面会调用刚才说的recycleUnchecked()方法，使得Message和Handler断开引用。当然也可以选择移除指定消息，一样的。
@Override
protected void onDestroy() {
super.onDestroy();
//移除消息队列
handler.removeCallbacksAndMessages(null);
}
方案2:
就是网上说的最多的那种，写个静态内部类来继承Handler，然后通过弱引用来访问Activity的内容。这种就不写了。
小结
内存泄漏问题的解决，最本质的内容还是GcRoot引用链，只要知道了引用关系，你就知道为什么有些对象暂时无法回收。
全局static静态变量
static静态变量强引用当前对象，会导致当前对象无法回收，造成内存泄漏。这一点应该没什么争议。网上流传一种观点，如果这个对象被频繁创建销毁，那么就会有多个对象无法被回收。那真的是这样吗？
public class MainActivity extends AppCompatActivity {
private static Context mContext;
@Override
protected void onCreate(@Nullable Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
mContext = this;
}
}
Q：考一下大家，如果反复进出当前Activity10次，请问会有多少个Activity对象泄漏？
A：按照网上的说法，是10个，但是真的这样吗？经过我的验证，答案是只有1个。关于验证方法，你可以通过AS的Profile工具去查看堆内存中创建的对象，当你进出10次的时候却是存在10个Activity对象，但是当你点击那个【强制执行gc回收】按钮的时候，你会发现只剩下1个对象了，其他的9个都被回收了。
首先类的static变量是全局唯一的，常驻内存的方法区。在当前对象被重新创建的时候，static变量会重新赋值，那么它之前所引用的对象就不再被
gc roots引用，这样的话是可以被gc回收的。换句话说，如果在gc回收的情况下，最多只有一个对象被泄漏。
其它案例，后面在补充吧。大家可以留言说说你的问题。
参考：
https://www.cnblogs.com/ldq2016/p/8473376.html
https://www.jianshu.com/p/3e59d129c05d
Android 静态变量导致的内存泄漏问题
