转自:http://imushan.com/2018/08/19/java/language/JDK源码阅读-Reference/

Java最初只有普通的强引用,只有对象存在引用,则对象就不会被回收,即使内存不足,也是如此,JVM会爆出OOME,也不会去回收存在引用的对象。
如果只提供强引用,我们就很难写出“这个对象不是很重要,如果内存不足GC回收掉也是可以的”这种语义的代码。Java在1.2版本中完善了引用体系,提供了4中引用类型:强引用,软引用,弱引用,虚引用。使用这些引用类型,我们不但可以控制垃圾回收器对对象的回收策略,同时还能在对象被回收后得到通知,进行相应的后续操作。

引用与可达性分类

Java目前有4中引用类型:

  1. 强引用(Strong Reference):普通的的引用类型,new一个对象默认得到的引用就是强引用,只要对象存在强引用,就不会被GC。
  2. 软引用(Soft Reference):相对较弱的引用,垃圾回收器会在内存不足时回收弱引用指向的对象。JVM会在抛出OOME前清理所有弱引用指向的对象,如果清理完还是内存不足,才会抛出OOME。所以软引用一般用于实现内存敏感缓存。
  3. 弱引用(Weak Reference):更弱的引用类型,垃圾回收器在GC时会回收此对象,也可以用于实现缓存,比如JDK提供的WeakHashMap。
  4. 虚引用(Phantom Reference):一种特殊的引用类型,不能通过虚引用获取到关联对象,只是用于获取对象被回收的通知。

相较于传统的引用计数算法,Java使用可达性分析来判断一个对象是否存活。其基本思路是从GC Root开始向下搜索,如果对象与GC Root之间存在引用链,则对象是可达的。对象的可达性与引用类型密切相关。Java有5中类型的可达性:

  1. 强可达(Strongly Reachable):如果线程能通过强引用访问到对象,那么这个对象就是强可达的。
  2. 软可达(Soft Reachable):如果一个对象不是强可达的,但是可以通过软引用访问到,那么这个对象就是软可达的
  3. 弱可达(Weak Reachable):如果一个对象不是强可达或者软可达的,但是可以通过弱引用访问到,那么这个对象就是弱可达的。
  4. 虚可达(Phantom Reachable):如果一个对象不是强可达,软可达或者弱可达,并且这个对象已经finalize过了,并且有虚引用指向该对象,那么这个对象就是虚可达的。
  5. 不可达(Unreachable):如果对象不能通过上述的几种方式访问到,则对象是不可达的,可以被回收。

对象的引用类型与可达性听着有点乱,好像是一回事,我们这里实例分析一下:
JDK源码阅读-Reference - 图1
上面这个例子中,A~D,每个对象只存在一个引用,分别是:A-强引用,B-软引用,C-弱引用,D-虚引用,所以他们的可达性为:A-强可达,B-软可达,C-弱可达,D-虚可达。因为E没有存在和GC Root的引用链,所以它是不可达。
在看一个复杂的例子:
JDK源码阅读-Reference - 图2

  • A依然只有一个强引用,所以A是强可达
  • B存在两个引用,强引用和软引用,但是B可以通过强引用访问到,所以B是强可达
  • C只能通过弱引用访问到,所以是弱可达
  • D存在弱引用和虚引用,所以是弱可达
  • E虽然存在F的强引用,但是GC Root无法访问到它,所以它依然是不可达。

同时可以看出,对象的可达性是会发生变化的,随着运行时引用对象的引用类型的变化,可达性也会发生变化,可以参考下图:
JDK源码阅读-Reference - 图3

Reference总体结构

Reference类是所有引用类型的基类,Java提供了具体引用类型的具体实现:
JDK源码阅读-Reference - 图4

  • SoftReference:软引用,堆内存不足时,垃圾回收器会回收对应引用
  • WeakReference:弱引用,每次垃圾回收都会回收其引用
  • PhantomReference:虚引用,对引用无影响,只用于获取对象被回收的通知
  • FinalReference:Java用于实现finalization的一个内部类

因为默认的引用就是强引用,所以没有强引用的Reference实现类。

Reference的核心

Java的多种引用类型实现,不是通过扩展语法实现的,而是利用类实现的,Reference类表示一个引用,其核心代码就是一个成员变量referent

  1. public abstract class Reference<T> {
  2. private T referent; // 会被GC特殊对待
  3. // 获取Reference管理的对象
  4. public T get() {
  5. return this.referent;
  6. }
  7. // ...
  8. }

如果JVM没有对这个变量做特殊处理,它依然只是一个普通的强引用,之所以会出现不同的引用类型,是因为JVM垃圾回收器硬编码识别SoftReferenceWeakReferencePhantomReference等这些具体的类,对其reference变量进行特殊对象,才有了不同的引用类型的效果。
上文提到了Reference及其子类有两大功能:

  1. 实现特定的引用类型
  2. 用户可以对象被回收后得到通知

第一个功能已经解释过了,第二个功能是如何做到的呢?
一种思路是在新建一个Reference实例是,添加一个回调,当java.lang.ref.Reference#referent被回收时,JVM调用该回调,这种思路比较符合一般的通知模型,但是对于引用与垃圾回收这种底层场景来说,会导致实现复杂,性能不高的问题,比如需要考虑在什么线程中执行这个回调,回调执行阻塞怎么办等等。
所以Reference使用了一种更加原始的方式来做通知,就是把引用对象被回收的Reference添加到一个队列中,用户后续自己去从队列中获取并使用。
理解了设计后对应到代码上就好理解了,Reference有一个queue成员变量,用于存储引用对象被回收的Reference实例:

  1. public abstract class Reference<T> {
  2. // 会被GC特殊对待
  3. private T referent;
  4. // reference被回收后,当前Reference实例会被添加到这个队列中
  5. volatile ReferenceQueue<? super T> queue;
  6. // 只传入reference的构造函数,意味着用户只需要特殊的引用类型,不关心对象何时被GC
  7. Reference(T referent) {
  8. this(referent, null);
  9. }
  10. // 传入referent和ReferenceQueue的构造函数,reference被回收后,会添加到queue中
  11. Reference(T referent, ReferenceQueue<? super T> queue) {
  12. this.referent = referent;
  13. this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
  14. }
  15. // ...
  16. }

Reference的状态

Reference对象是有状态的。一共有4中状态:

  1. Active:新创建的实例的状态,由垃圾回收器进行处理,如果实例的可达性处于合适的状态,垃圾回收器会切换实例的状态为Pending或者Inactive。如果Reference注册了ReferenceQueue,则会切换为Pending,并且Reference会加入pending-Reference链表中,如果没有注册ReferenceQueue,会切换为Inactive
  2. Pending:在pending-Reference链表中的Reference的状态,这些Reference等待被加入ReferenceQueue中。
  3. Enqueued:在ReferenceQueue队列中的Reference的状态,如果Reference从队列中移除,会进入Inactive状态
  4. Inactive:Reference的最终状态

Reference对象图如下:
JDK源码阅读-Reference - 图5
除了上文提到的ReferenceQueue,这里出现了一个新的数据结构:pending-Reference。这个链表是用来干什么的呢?
上文提到了,reference引用的对象被回收后,该Reference实例会被添加到ReferenceQueue中,但是这个不是垃圾回收器来做的,这个操作还是有一定逻辑的,如果垃圾回收器还需要执行这个操作,会降低其效率。从另外一方面想,Reference实例会被添加到ReferenceQueue中的实效性要求不高,所以也没必要在回收时立马加入ReferenceQueue
所以垃圾回收器做的是一个更轻量级的操作:把Reference添加到pending-Reference链表中。Reference对象中有一个pending成员变量,是静态变量,它就是这个pending-Reference链表的头结点。要组成链表,还需要一个指针,指向下一个节点,这个对应的是java.lang.ref.Reference#discovered这个成员变量。
可以看一下代码:

  1. public abstract class Reference<T> {
  2. // 会被GC特殊对待
  3. private T referent;
  4. // reference被回收后,当前Reference实例会被添加到这个队列中
  5. volatile ReferenceQueue<? super T> queue;
  6. // 全局唯一的pending-Reference列表
  7. private static Reference<Object> pending = null;
  8. // Reference为Active:由垃圾回收器管理的已发现的引用列表(这个不在本文讨论访问内)
  9. // Reference为Pending:在pending列表中的下一个元素,如果没有为null
  10. // 其他状态:NULL
  11. transient private Reference<T> discovered; /* used by VM */
  12. // ...
  13. }

ReferenceHandler线程

通过上文的讨论,我们知道一个Reference实例化后状态为Active,其引用的对象被回收后,垃圾回收器将其加入到pending-Reference链表,等待加入ReferenceQueue。这个过程是如何实现的呢?
这个过程不能对垃圾回收器产生影响,所以不能在垃圾回收线程中执行,也就需要一个独立的线程来负责。这个线程就是ReferenceHandler,它定义在Reference类中:

  1. // 用于控制垃圾回收器操作与Pending状态的Reference入队操作不冲突执行的全局锁
  2. // 垃圾回收器开始一轮垃圾回收前要获取此锁
  3. // 所以所有占用这个锁的代码必须尽快完成,不能生成新对象,也不能调用用户代码
  4. static private class Lock { };
  5. private static Lock lock = new Lock();
  6. private static class ReferenceHandler extends Thread {
  7. ReferenceHandler(ThreadGroup g, String name) {
  8. super(g, name);
  9. }
  10. public void run() {
  11. // 这个线程一直执行
  12. for (;;) {
  13. Reference<Object> r;
  14. // 获取锁,避免与垃圾回收器同时操作
  15. synchronized (lock) {
  16. // 判断pending-Reference链表是否有数据
  17. if (pending != null) {
  18. // 如果有Pending Reference,从列表中取出
  19. r = pending;
  20. pending = r.discovered;
  21. r.discovered = null;
  22. } else {
  23. // 如果没有Pending Reference,调用wait等待
  24. //
  25. // wait等待锁,是可能抛出OOME的,
  26. // 因为可能发生InterruptedException异常,然后就需要实例化这个异常对象,
  27. // 如果此时内存不足,就可能抛出OOME,所以这里需要捕获OutOfMemoryError,
  28. // 避免因为OOME而导致ReferenceHandler进程静默退出
  29. try {
  30. try {
  31. lock.wait();
  32. } catch (OutOfMemoryError x) { }
  33. } catch (InterruptedException x) { }
  34. continue;
  35. }
  36. }
  37. // 如果Reference是Cleaner,调用其clean方法
  38. // 这与Cleaner机制有关系,不在此文的讨论访问
  39. if (r instanceof Cleaner) {
  40. ((Cleaner)r).clean();
  41. continue;
  42. }
  43. // 把Reference添加到关联的ReferenceQueue中
  44. // 如果Reference构造时没有关联ReferenceQueue,会关联ReferenceQueue.NULL,这里就不会进行入队操作了
  45. ReferenceQueue<Object> q = r.queue;
  46. if (q != ReferenceQueue.NULL) q.enqueue(r);
  47. }
  48. }
  49. }

ReferenceHandler线程是在Reference的static块中启动的:

  1. static {
  2. // 获取system ThreadGroup
  3. ThreadGroup tg = Thread.currentThread().getThreadGroup();
  4. for (ThreadGroup tgn = tg;
  5. tgn != null;
  6. tg = tgn, tgn = tg.getParent());
  7. Thread handler = new ReferenceHandler(tg, "Reference Handler");
  8. // ReferenceHandler线程有最高优先级
  9. handler.setPriority(Thread.MAX_PRIORITY);
  10. handler.setDaemon(true);
  11. handler.start();
  12. }

综上,ReferenceHandler是一个最高优先级的线程,其逻辑是从Pending-Reference链表中取出Reference,添加到其关联的Reference-Queue中。

ReferenceQueue

Reference-Queue也是一个链表:

  1. public class ReferenceQueue<T> {
  2. private volatile Reference<? extends T> head = null;
  3. // ...
  4. }
  1. // ReferenceQueue中的这个锁用于保护链表队列在多线程环境下的正确性
  2. static private class Lock { };
  3. private Lock lock = new Lock();
  4. boolean enqueue(Reference<? extends T> r) { /* Called only by Reference class */
  5. synchronized (lock) {
  6. // 判断Reference是否需要入队
  7. ReferenceQueue<?> queue = r.queue;
  8. if ((queue == NULL) || (queue == ENQUEUED)) {
  9. return false;
  10. }
  11. assert queue == this;
  12. // Reference入队后,其queue变量设置为ENQUEUED
  13. r.queue = ENQUEUED;
  14. // Reference的next变量指向ReferenceQueue中下一个元素
  15. r.next = (head == null) ? r : head;
  16. head = r;
  17. queueLength++;
  18. if (r instanceof FinalReference) {
  19. sun.misc.VM.addFinalRefCount(1);
  20. }
  21. lock.notifyAll();
  22. return true;
  23. }
  24. }

通过上面的代码,可以知道java.lang.ref.Reference#next的用途了:

  1. public abstract class Reference<T> {
  2. /* When active: NULL
  3. * pending: this
  4. * Enqueued: 指向ReferenceQueue中的下一个元素,如果没有,指向this
  5. * Inactive: this
  6. */
  7. Reference next;
  8. // ...
  9. }

总结

一个使用Reference+ReferenceQueue的完整流程如下:
JDK源码阅读-Reference - 图6

参考资料