Java引用类型
Java引用主要分为4种（其实似乎是5种）：
-
Strong Reference 强引用，直接引用 -
Soft Reference 软引用，间接引用 -
Weak Reference 弱引用，间接引用 -
Phantom Reference 虚引用，几乎无引用 - Final引用，这里不介绍
强引用
Object strongReference = new Object();
我们平常使用最多的就是强引用。按照JVM规范，在GC时通过可达性分析检测到强引用可达时，这个对象不会被回收。
但是在某些情况下，强引用的这个特性会引起OutOfMemoryError，比如一直向集合中添加元素。
软引用
软引用对象仅在内存不足时会被回收，JVM保证在抛出OutOfMemoryError之前已经将软引用对象全部清理了。
弱引用
JVM不保证弱引用对象的回收时机，在GC线程发现该对象为弱引用对象时就会回收。
虚引用
任何时候都可能会被回收。
Java提供了几种间接引用方式，有什么好处吗？是如何起作用的？我们从源码中一点一点看。
Reference和ReferenceQueue
ReferenceQueue
ReferenceQueue本质上是一个单向链表，链表的节点是Reference，并提供了同步非阻塞出队方法poll()。
同时，ReferenceQueue提供了一个类似BlockingQueue的阻塞获取节点的方法remove()。
在Reference类的构造方法中，可以指定一个ReferenceQueue。
Reference
Java的强软弱虚四种中，软、弱、虚引用都是继承Reference<T>抽象类。
核心的几个属性和方法：
public abstract class Reference<T> {
......
private T referent; // 代管的对象
......
volatile ReferenceQueue<? super T> queue; // 关联的通知队列
......
private static Reference<Object> pending = null; // 静态的待处理链
......
static boolean tryHandlePending(boolean waitForNotify) {......} // 负责检查pending链等关键操作
......
public T get() { return this.referent; } // 获取直接引用
......
}
Reference类相当于引用代理，正常情况下我们持有Reference对象的引用，Reference对象持有我们真正使用的对象T referent的引用。
Reference提供了几个重要的方法：
-
get()获取代管对象（referent）的直接引用 -
isEnqueued()检查是否还在队列中 -
tryHandlePending()如果存在可回收的Reference，则将这个Reference插入到构造方法指定的ReferenceQueue中；否则wait()等待
其中，Reference创建了一个名为“Reference Handler”的常驻后台线程，用于将referent已被回收的Reference对象加入其引用通知队列ReferenceQueue。
Reference中的referent
Reference中的referent会受到GC的特殊对待：
- GC检测到
reference.referent（非静态）引用可达性发生变化时，会将对应的Reference对象挂在Reference.pending（静态）链上
ps.文档未介绍“可达性发生变化”是什么情况，我猜测是处于“仅Reference对象持有直接引用”的状态。这个状态按理说是不能回收的，因为引用分析是可达的，但这里特殊处理，即使可达GC也可以回收。
综合看Reference和ReferenceQueue
这两个类形成了一个回收通知机制：
- 新建一个Reference对象，在构造方法中为其绑定一个间接引用对象referent，及一个回收通知队列referenceQueue
- 去除referent的其他直接引用
- Reference类在应用启动时就创建了Reference Handler线程，但
Reference.tryHandlePending方法发现pending对象为null，线程进入WAIT状态，pending保存的是需要回收的Reference链的首个节点 - GC在回收这个Reference对象的referent时，将其Reference对象挂在Reference.pending链上，即GC会将所有达到可回收状态的Reference对象挂到静态的pending链上
- Reference Handler线程被唤醒，通过
Reference.tryHandlePending方法发现pending中有内容，将链上的Reference对象插入其构造方法指定的referenceQueue中（当然，如果没有指定那么就不会入队） - 我们通过referenceQueue的
remove()阻塞或poll()非阻塞方法可以拿到哪些Reference对象的referent已被回收，可以进行接下来的善后处理
应用场景
- 软引用
官方文档提到，软引用非常适合用于内存敏感的缓存，当内存不足时GC将会回收缓存中的部分内容。
ps.有参考资料提到软引用可能导致频繁Full GC。 - 弱引用
官方文档提到，弱引用适合用于规范化映射（Canonicalizing Mappings），可以理解为一个Map中的KV映射。 - 虚引用
PhantomReference.get()方法永远返回null，因此一旦失去直接引用仅保留虚引用，那么就无法再获取这个对象的引用。适合用于监控对象是否被回收。
一个典型的应用就是WeakHashMap类。
WeakHashMap中的Entry继承自WeakReference类，其中key就是间接引用中的referent，获取key均是通过Reference对象的get()方法，即有可能失效。
另外，WeakHashMap持有一个ReferenceQueue对象，每个Entry都在构造方法中关联了这个queue。
其expungeStaleEntries()方法会清理失效的Entry，作为大多数方法的前置操作。
结合上边的回收通知机制等分析，WeakHashMap有这些特点：
- 使用弱引用作为Entry，referent是Entry的key，并关联了一个内部的ReferenceQueue
- 每次GC时都会清理掉一部分Entry的referent，key变为null——相当于这些内容在Map中“消失”了，不过value占用的空间还没清理
- key被清理的Entry，如前所述会进入回收通知队列ReferenceQueue
- 在绝大部分操作之前会先从回收通知队列中获取失效的Entry，并从Map中真正删除
回收通知机制的好处
- GC虽然做了特殊处理，但是插入链表这个额外的操作相对来说负担是非常小的，对GC影响不大，回收通知机制后续的逻辑其实是Reference Handler线程在做。
- 使用间接引用后，如何清理被回收的数据及相关数据，或者如何接收被回收通知是个问题。
以WeakHashMap举例，被回收的数据都在ReferenceQueue中，比起遍历整个集合查看哪些数据被回收了，显然使用通知机制仅查这个queue效率要高得多。
参考资料
JDK源码阅读-Reference
Java Reference详解 - robin-yao的个人页面 - OSCHINA
Java 理论与实践: 用弱引用堵住内存泄漏
本文搬自我的博客，欢迎参观！
