java中的reference(二): jdk1.8中Reference的源码阅读

[toc]

1. java1.8 中的Reference结构

在jdk1.8中，Reference位于java.lan.ref包中。

image.png

主要的类有:Reference、SoftReference、WeakReference、PhantomReference及FinalReference、和Finalizer。其中最核心的是抽象类Reference，其他的Reference都继承了这个抽象类。分别对应java的软、弱、虚引用。而强引用是系统缺省的引用关系，用等号即可表示。因此没有专门的类。另外还有一个FinalReference,这个类主要是配合Finalizer机制使用。Finalizer本身存在诸多问题，在jdk1.9中已经被替换为另外一种Cleaner机制来配合PhantomReference机制，本文暂不涉及jdk1.9中的内容仅限于jdk1.8。
还有一个关键的类是ReferenceQueue,
java.lan.ref包中各类的关系如下图：

image.png

也可以通过idea提供的Diagram查看：

image.png

上述Reference总结见下表：

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

2. 引用与可达性

要搞懂Reference，必须要对GC的过程进行进一步的了解。
我们在前文中已经体会了jvm中定义的这些引用的具体用法。
我们知道，GC决定是否对一个对象进行回收，主要根据的是从GC ROOT 节点往下搜索，进行可达性计算。GC根据可达性结果决定是否对这些对象进行回收。可达性主要有五种，分别与这4种引用类型进行对应。

可达性类型	引用类型	说明
强可达(Strongly Reachable)	强引用(Strong Reference)	如果线程能通过强引用访问到对象，那么这个对象就是强可达的。
软可达(Soft Reachable)	软引用(Soft Reference)	如果一个对象不是强可达的，但是可以通过软引用访问到，那么这个对象就是软可达的
弱可达(Weak Reachable)	弱引用(Weak Reference)	如果一个对象不是强可达或者软可达的，但是可以通过弱引用访问到，那么这个对象就是弱可达的。
虚可达(Phantom Reachable)	虚引用(Phantom Reference)	如果一个对象不是强可达，软可达或者弱可达，并且这个对象已经finalize过了，并且有虚引用指向该对象，那么这个对象就是虚可达的。
不可达(Unreachable)	-	如果一个对象不是强可达，软可达或者弱可达，并且这个对象已经finalize过了，并且有虚引用指向该对象，那么这个对象就是虚可达的。

这是可达性的概念，我们可以通过如下示例进一步分析：

image.png

在上面这个例子中，A~D，每个对象只存在一个引用，分别是：A-强引用，B-软引用，C-弱引用，D-虚引用，所以他们的可达性为：A-强可达，B-软可达，C-弱可达，D-虚可达。因为E没有存在和GC Root的引用链，所以它是不可达。
再看如下这个更加复杂的例子：

image.png

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

这是jvm种的5种可达性。不难看出，jvm主要是根据这些Reference的4种子类，来实现GC面对这些对象不可达的时候的不同处理办法。

3. Reference源码

3.1 核心源码

首先来看Reference源码

/**
 * Abstract base class for reference objects.  This class defines the
 * operations common to all reference objects.  Because reference objects are
 * implemented in close cooperation with the garbage collector, this class may
 * not be subclassed directly.
 *
 * @author   Mark Reinhold
 * @since    1.2
 */

注释说，这个抽象类是所有Reference类的基类，定义了所有Reference相关的操作，与GC紧密关联。也就是说GC会根据这些类来做一些特定的处理，直接实现其子类没有意义。什么意思，也就是说，jvm会对这个类及其子类做特殊的处理，jvmGC程序会硬编码识别SoftReference，WeakReference，PhantomReference等这些具体的类，对其reference变量进行特殊对象，才有了不同的引用类型的效果。否则，Reference与普通的类没啥区别。
Reference 主要实现两大核心功能：

• 实现特定的引用类型
• 用户可以对象被回收后得到通知
  那么第一个功能在此已经可以很明白了。对于第二个功能，GC如何实现垃圾回收之后发送消息通知呢？很显然，对于GC这种性能要求很高的场景，不能采用传统的消息回调模式。万一再FullGC重消息回调阻塞或者出现性能问题，那么会导致整个JVM挂起。所以，Reference采用了另外一种方式，把被回收的Reference添加到了一个队列中。后续用户根据需要自行从queue中获取。这也解释了为啥软、弱引用提供了两调用方式，可以选择ReferenceQueue一起使用，也可以不用。但是虚引用由于只有通知消息，必须和ReferenceQuene一起使用。
  现在查看Reference的源码：

public abstract class Reference {
    //会被GC特殊对待
    private T referent;         /* Treated specially by GC */ 
    //Reference被回收之后会被添加到这个queue
    volatile ReferenceQueue queue;
    
    
    /* -- Constructors -- */
    //用户只需要特殊的Reference，并不关心GC状态，因此可以不需要ReferenceQueue
    Reference(T referent) {
        this(referent, null);
    }
    //构造函数中传入了queue,如果reference被GC回收，则会添加到queue中去
    Reference(T referent, ReferenceQueue queue) {
        this.referent = referent;
        this.queue = (queue == null) ? ReferenceQueue.NULL : queue;
    }

}

3.2 reference的状态

再Reference中，定义了Reference的状态：

 /* A Reference instance is in one of four possible internal states:
     *
     *     Active: Subject to special treatment by the garbage collector.  Some
     *     time after the collector detects that the reachability of the
     *     referent has changed to the appropriate state, it changes the
     *     instance's state to either Pending or Inactive, depending upon
     *     whether or not the instance was registered with a queue when it was
     *     created.  In the former case it also adds the instance to the
     *     pending-Reference list.  Newly-created instances are Active.
     *
     *     Pending: An element of the pending-Reference list, waiting to be
     *     enqueued by the Reference-handler thread.  Unregistered instances
     *     are never in this state.
     *
     *     Enqueued: An element of the queue with which the instance was
     *     registered when it was created.  When an instance is removed from
     *     its ReferenceQueue, it is made Inactive.  Unregistered instances are
     *     never in this state.
     *
     *     Inactive: Nothing more to do.  Once an instance becomes Inactive its
     *     state will never change again.
     *
     * The state is encoded in the queue and next fields as follows:
     *
     *     Active: queue = ReferenceQueue with which instance is registered, or
     *     ReferenceQueue.NULL if it was not registered with a queue; next =
     *     null.
     *
     *     Pending: queue = ReferenceQueue with which instance is registered;
     *     next = this
     *
     *     Enqueued: queue = ReferenceQueue.ENQUEUED; next = Following instance
     *     in queue, or this if at end of list.
     *
     *     Inactive: queue = ReferenceQueue.NULL; next = this.
     *
     * With this scheme the collector need only examine the next field in order
     * to determine whether a Reference instance requires special treatment: If
     * the next field is null then the instance is active; if it is non-null,
     * then the collector should treat the instance normally.
     *
     * To ensure that a concurrent collector can discover active Reference
     * objects without interfering with application threads that may apply
     * the enqueue() method to those objects, collectors should link
     * discovered objects through the discovered field. The discovered
     * field is also used for linking Reference objects in the pending list.
     */

大段的英文注释，实际上在学习java源代码的过程中，看懂这些注释往往比源码更加重要，有时候源码只能反应实现的具体过程，但是究竟为什么要真没实现，则在很多源码的注释中有说明。
注释中，将Reference的状态分为4种：

状态	说明
Active	刚初始化的实例是Active状态，在可达性发生变化之后，由于GC的各种特殊处理，可能会切换为Pendig或者Inactive状态，如果实例创建时注册了referenceQueue,则会切换到Pending状态，并将Reference加入到Pending-Reference队列，如果没有注册ReferenceQueue,则会切换到Inactive状态
Pending	当被加入到Penging-reference链表中的时候的状态，这些Reference等待被加入到ReferenceQueue。如果没有注册ReferenceQueue则永远不会出现这个状态
Enqueued	在ReferenceQueue队列中的Reference的状态，如果从ReferenceQueue中移除，则会进入Inactive状态
Inactive	Reference的最终状态，一旦到达Inactive状态则状态不会再发生改变

对于这四种状态，Reference的next指针和queue如下：

状态	queue	next
Active	ReferenceQueue or ReferenceQueue.NULL	null
Pending	ReferenceQueue	this
Enqueued	ReferenceQueue.ENQUEUED	队列中的下一个
Inactive	ReferenceQueue.NULL	this

状态图如下：

image.png

在上文注释中我们发现有一个Penging-reference链表，还有一个ReferenceQueue。这个链表又是来做什么的呢？常规来说，jvm应该直接将gc后的Referencce加入到ReferenceQueue中即可。但是实际上并不是如此。GC为了保证执行效率，而ReferenceQueue中的数据本身也不需要那么高的时效性，因此，在具体的代码中，jvm的GC操作只把Reference加入到了pending-Reference链表中。这是一个轻量级的操作，效率会非常高。Reference中有一个pending的成员变量，他就是这个pending-Reference链表的头节点。而discoverd 则是指向下一个节点的指针。
我们再看看Reference源码：

    /* List of References waiting to be enqueued.  The collector adds
     * References to this list, while the Reference-handler thread removes
     * them.  This list is protected by the above lock object. The
     * list uses the discovered field to link its elements.
     */
    private static Reference