在工作实践中发现，大家写的代码很容易发生内存泄漏，我觉得这个主要问题是大家对弱引用和 gc root 的理解不够深导致，所以，打算写(水)一篇我的理解。
在 维基百科中对弱引用的解释是：
在计算机程序设计中，弱引用与强引用相对，是指不能确保其引用的对象不会被垃圾回收器回收的引用。一个对象若只被弱引用所引用，则被认为是不可访问（或弱可访问）的，并因此可能在任何时刻被回收
这个意思也很简单，简单翻译一下：
默认我们 new 创建的对象都是强引用，我们可以创建个弱引用来关联这个引用对象，但如果这个对象没有被强引用，只剩下弱引用与他有关联，则认为在任何时刻都可能被回收。 那什么情况下强引用不与对象产生关联呢？那就是 gc 回收时，也即意味着强引用被回收了，则弱引用关联的强引用就会变为不可访问的引用(这句话很重要)。
谁可以作为 gc root？
引用自《深入理解 Java 虚拟机》:
1、在虚拟机栈(栈帧中的本地变量表)，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等。
2、在方法区中类静态属性引用的对象，譬如 java 类的引用类型静态变量。
3、在方法区中常量引用的对象，譬如字符串常量池里的引用。
4、在本地方法栈中 JNI 引用的对象。
5、Java 虚拟机内部的引用，如基本数据类型对应的 class 对象，一些常驻的异常对象等，还有类加载器。
6、所有被同步锁持有的对象。
7、反映 Java 虚拟机内部情况的 JMXBean、JVMTI 中注册的回调、本地代码缓存等。
作为 gc root 的条件有很多，下面拿 2 和 5 这两种 gc root 来讲解
例子：
// Test.java public class Test { private static final Test s = new Test(); public static Test getInstance(){ return s; } Context context; public void setContext(Context context){ this.context = context; } } // TestActivity.java public class TestActivity extends AppCompatActivity{ public void onCreate(Bundle onSaveInstance){ Test.getInstance().setContext(this) } } 复制代码
在启动 TestActivity 的时候，onCreate 方法将当前的 Context 引用设置给 Test，我们来画个引用链图：
在 TestActivity 进行页面销毁时，会执行 ActivityThread 的 performDestroyActivity 方法，该方法会把 TestActivity 从 mActivities 集合中移除，也就是断开引用，使其能被 gc 回收掉，执行之后的图：
可惜的是，TestActivity 虽然从 ActivityThread 的 gc root 引用链中被移除，但又被 Test 的 gc root 给强引用，导致 TestActivity 的整个引用链无法被释放而出现内存泄漏。
这时候就要用弱引用去解，Test 不去强引用 TestActivity，而是通过弱引用去关联强引用，如果强引用被回收的话，则弱引用也变为不可访问，也即我们通常遇到的 weakRef.get() 是空的情况，我们需要改一下 Test 的 setContext 方法：
Context context; public void setContext(Context context){ WeakReference<Context> contextRef = new WeakReference<>(context); context = contextRef.get(); } 复制代码
这时，我们的引用链图如下：
TestActivity 没有被任何依赖强引用，在 gc 到来时，TestActivity 则会被回收，Test 类中持有的弱引用 context 值会变成空，最终为：
总结：
如上只是用单例这种情况去做了一个分析，当然还有匿名内部类持有外部引用这种，如 Handler，道理都是一样，万变不离其宗，对于 Handler 的引用链分析可以看虾哥的文章《一次性讲清楚 Handler 可能导致的内存泄漏和解决办法》
对于弱引用怎么用，就是要看在 2 个及以上的 gc root 中是否都对同一个对象持有引用，如果有，则可以用弱引用去隔离开
