JDK源码分析（7）之 Reference 框架概览

对于reference类大家可能会比较陌生，平时用的也比较少，对他的印象可能仅停在面试的时候查看引用相关的知识点；但在仔细查看源码后发现reference还是非常实用的，平时我们使用的类都是强引用的，它的回收完全依赖于 gc；但是对于有些类我们想要自己控制的时候就比较麻烦，比如我想在内存还足够的时候就保留，不够的时候就回收，这时使用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
 */
public abstract class reference<t> {}

从注释和类图中可以清楚的看到：

• reference类是直接配合gc操作的，所以不能直接子类化，但是可以继承reference的子类；
• reference类定义了子类的主要逻辑，所以在softreference、weakreference和phantomreference中几乎完全复用了reference的逻辑；

二、reference 框架结构

如图所示，reference 的处理流程相当于事件处理

1. 如果 new reference 的时候如果没有传入 referencequeue，相当于使用 jvm 的默认处理流程，达到一定条件的时候由gc回收；
2. 如果 new reference 的时候传入了 referencequeue，相当于使用自定义的事件处理流程，此时的 referencequeue 相当于事件监听器，reference 则相当于每个事件，gc 标记的时候添加 discovered链表 相当于事件发现过程，pending和enqueued则相当于注册事件的过程，最后需要用户自定义事件处理逻辑；

在 reference 的生命周期里面，一共有四个状态：

• active：每个引用的创建之初都是活动状态，直到下次 gc 的时候引用的强弱关系发生变化，同时不同的引用根据不同的策略改变状态；
• pending：正准备加入引用链表；
• enqueued：已经加入引用链表，相当于已经注册成功等待处理；
• inactive：所有的引用对象的终点，可回收状态；

三、可达性分析

上面我们提到当引用强弱关系发生变化的时候，他的状态会发生改变，那么这个强弱关系是如何判断的呢？
熟悉 jvm 的同学应该知道判断对象是否存活的算法大致有两种；

1. 引用计数法，即每当有一个对象引用他的时候就加1，引用失效时减1，当任何时候计数都为0时，就代表对象可以被回收了；
2. 可达性分析法，即从一组 gc roots 对象出发，引用可达即代表存活，引用不可达就代表是可回收对象；如图所示：

上图仅表示了，强引用的回收，当加入了软引用，弱引用和虚应用之后：

• 单路径中，以最弱的引用为准
• 多路径中，以最强的引用为准

已上图为例：

• 对于 obj 1：单路径可达，所以 gc roots 到 obj 1为弱引用；
• 对于 obj 5：多路径可达，所以 gc roots 到 obj 5为软引用；

四、成员变量和构造函数

private t referent; /* treated specially by gc */
volatile referencequeue<? super t> queue;
volatile reference next;
transient private reference<t> discovered; /* used by vm */
private static reference<object> pending = null;

reference(t referent) {
  this(referent, null);
}

reference(t referent, referencequeue<? super t> queue) {
  this.referent = referent;
  this.queue = (queue == null) ? referencequeue.null : queue;
}

• referent：引用指向的对象，即需要reference包装的对象；
• queue：虽然referencequeue的名字里面有队列，但是它的内部却没有包含任何队列和链表的结构；他的内部封装了单向链表的添加，删除和遍历等操作，实际作用相当于事件监听器；
• next：引用单向链表；
• discovered：discovered单向链表，由 jvm 维护；在 gc 标记的时候，当引用强弱关系达到一定条件时，由 jvm 添加；需要注意的是这个字段是 transient 修饰的，但是 reference 类声明的时候却没有实现 serializable 接口，这是因为 reference 子类的子类可能实现 serializable 接口，另外一般情况下也不建议实现 serializable 接口；
• pending：表示正在排队等待入队的引用；

五、重要函数

1. 初始化

static {
  threadgroup tg = thread.currentthread().getthreadgroup();
  for (threadgroup tgn = tg;
    tgn != null;
    tg = tgn, tgn = tg.getparent());
  thread handler = new referencehandler(tg, "reference handler");
  /* if there were a special system-only priority greater than
   * max_priority, it would be used here
   */
  handler.setpriority(thread.max_priority);
  handler.setdaemon(true);
  handler.start();

  // provide access in sharedsecrets
  sharedsecrets.setjavalangrefaccess(new javalangrefaccess() {
    @override
    public boolean tryhandlependingreference() {
      return tryhandlepending(false);
    }
  });
}

可以看到在初始化的时候首先得到了层级最高的线程组即 system线程组，然后在里面加入了一个名为 “reference handler” 的 优先级最高 的 referencehandler 线程；
接下来的一段代码是用于保证 jvm 在抛出 oom 之前，原子性的清除非强引用的所有引用，如果空间仍然不足才会抛出 oom；其中 sharedsecrets用于访问类的私有变量，于反射不同的是，它不会创建新的对象；比如：

package java.nio;
// class bits
static void reservememory(long size, int cap) {
  ...
  // optimist!
  if (tryreservememory(size, cap)) {
    return;
  }
  
  // 走到这里就说明空间已经不足了
  final javalangrefaccess jlra = sharedsecrets.getjavalangrefaccess();
  
  // retry while helping enqueue pending reference objects
  // which includes executing pending cleaner(s) which includes
  // cleaner(s) that free direct buffer memory
  while (jlra.tryhandlependingreference()) {
   if (tryreservememory(size, cap)) {
     return;
   }
  }
  ...
}

有关 “reference handler” 的线程信息可以使用jstack [] <pid>抓取栈信息查看：

"reference handler" #2 daemon prio=10 os_prio=0 tid=0x00007fa1ac154170 nid=0x32a7 in object.wait() [0x00007fa19661f000]
   java.lang.thread.state: waiting (on object monitor)
    at java.lang.object.wait(native method)
    at java.lang.object.wait(object.java:502)
    at java.lang.ref.reference.tryhandlepending(reference.java:191)
    - locked <0x00000006c7e79bc0> (a java.lang.ref.reference$lock)
    at java.lang.ref.reference$referencehandler.run(reference.java:153)

2. referencehandler 线程

private static class referencehandler extends thread {
  private static void ensureclassinitialized(class<?> clazz) {
    try {
      class.forname(clazz.getname(), true, clazz.getclassloader());
    } catch (classnotfoundexception e) {
      throw (error) new noclassdeffounderror(e.getmessage()).initcause(e);
    }
  }

  static {
    // pre-load and initialize interruptedexception and cleaner classes
    // so that we don't get into trouble later in the run loop if there's
    // memory shortage while loading/initializing them lazily.
    ensureclassinitialized(interruptedexception.class);
    ensureclassinitialized(cleaner.class);
  }

  referencehandler(threadgroup g, string name) {
    super(g, name);
  }

  public void run() {
    while (true) {
      tryhandlepending(true);
    }
  }
}

可以看到这个线程只做了一件很简单的事情：

• 首先确保interruptedexception和cleaner已经加载，关于cleaner就是一个虚引用的实际应用，后面还会详细讲到；
• 然后死循环执行tryhandlepending；

3. tryhandlepending 核心方法

/**
 * try handle pending {@link reference} if there is one.<p>
 * return {@code true} as a hint that there might be another
 * {@link reference} pending or {@code false} when there are no more pending
 * {@link reference}s at the moment and the program can do some other
 * useful work instead of looping.
 *
 * @param waitfornotify if {@code true} and there was no pending
 *                      {@link reference}, wait until notified from vm
 *                      or interrupted; if {@code false}, return immediately
 *                      when there is no pending {@link reference}.
 * @return {@code true} if there was a {@link reference} pending and it
 *         was processed, or we waited for notification and either got it
 *         or thread was interrupted before being notified;
 *         {@code false} otherwise.
 */
static boolean tryhandlepending(boolean waitfornotify) {
  reference<object> r;
  cleaner c;
  try {
    synchronized (lock) {
      if (pending != null) {
        r = pending;
        // 'instanceof' might throw outofmemoryerror sometimes
        // so do this before un-linking 'r' from the 'pending' chain...
        c = r instanceof cleaner ? (cleaner) r : null;
        // unlink 'r' from 'pending' chain
        pending = r.discovered;
        r.discovered = null;
      } else {
        // the waiting on the lock may cause an outofmemoryerror
        // because it may try to allocate exception objects.
        if (waitfornotify) {
          lock.wait();
        }
        // retry if waited
        return waitfornotify;
      }
    }
  } catch (outofmemoryerror x) {
    // give other threads cpu time so they hopefully drop some live references
    // and gc reclaims some space.
    // also prevent cpu intensive spinning in case 'r instanceof cleaner' above
    // persistently throws oome for some time...
    thread.yield();
    // retry
    return true;
  } catch (interruptedexception x) {
    // retry
    return true;
  }

  // fast path for cleaners
  if (c != null) {
    c.clean();
    return true;
  }

  referencequeue<? super object> q = r.queue;
  if (q != referencequeue.null) q.enqueue(r);
  return true;
}

这个方法主要完成了discovered -> pending -> enqueued的整个入队注册流程；值得注意的是虽然cleaner是虚引用，但是它并不会入队，而是直接执行clean操作，也就意味着在使用cleaner的时候不需要在起一个线程监听referencequeue了；

4. referencequeue 概览

static referencequeue<object> null = new null<>();

// 用于标记是否已经入队，防止重复入队
static referencequeue<object> enqueued = new null<>();
private volatile reference<? extends t> head = null;
private long queuelength = 0;

// reference入队操作
boolean enqueue(reference<? extends t> r) { /* called only by reference class */

// poll 移除reference链表头元素
public reference<? extends t> poll() { }

// 移除reference链表下一个元素
public reference<? extends t> remove(long timeout) { }
public reference<? extends t> remove() throws interruptedexception { }
void foreach(consumer<? super reference<? extends t>> action) { }

从上面的代码也可以看出referencequeue的确没有包含任何链表或者队列的结构，但是封装了单向的链表的操作；

总结

• reference 主要用于更加灵活的控制对象的生死，其实现类似于事件处理，可以是 jvm 默认处理，也可以是用户自定义的处理逻辑；
• 在 java 语言中 reference 类定义了子类（softreference，weakreference，phantomreference）的主要逻辑，但是判断引用回收的条件主要在 jvm 中定义（主要发生在 gc 标记阶段），如果你有兴趣可以到 openjdk 里面继续深入研究；
• 如果在使用 reference 的时候传入了 referencequeue，即使用自定义的逻辑处理，那么最后一定要把 referencequeue 中注册的 reference 移除，因为此时 gc 不会回收 referencequeue 中的链表；
• reference handler 线程只有一个，但是 reference 链表却有很多条（所以在注册的时候需要加锁），另外每个 class 对象都能同时生成多个引用对象，并注册 referencequeue ；