JDK源碼分析（7）之 Reference 框架概覽

對於Reference類你們可能會比較陌生，平時用的也比較少，對他的印象可能僅停在面試的時候查看引用相關的知識點；但在仔細查看源碼後發現Reference仍是很是實用的，平時咱們使用的類都是強引用的，它的回收徹底依賴於 GC；可是對於有些類咱們想要本身控制的時候就比較麻煩，好比我想在內存還足夠的時候就保留，不夠的時候就回收，這時使用Reference就可以十分靈活的控制類的存亡了。

1、類定義

/**
 * 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的邏輯；

2、Reference 框架結構

如圖所示，Reference 的處理流程至關於事件處理

1. 若是 new Reference 的時候若是沒有傳入 ReferenceQueue，至關於使用 JVM 的默認處理流程，達到必定條件的時候由GC回收；
2. 若是 new Reference 的時候傳入了 ReferenceQueue，至關於使用自定義的事件處理流程，此時的 ReferenceQueue 至關於事件監聽器，Reference 則至關於每一個事件，GC 標記的時候添加 discovered鏈表 至關於事件發現過程，pending和enqueued則至關於註冊事件的過程，最後須要用戶自定義事件處理邏輯；

在 Reference 的生命週期裏面，一共有四個狀態：

• Active：每一個引用的建立之初都是活動狀態，直到下次 GC 的時候引用的強弱關係發生變化，同時不一樣的引用根據不一樣的策略改變狀態；
• Pending：正準備加入引用鏈表；
• Enqueued：已經加入引用鏈表，至關於已經註冊成功等待處理；
• Inactive：全部的引用對象的終點，可回收狀態；

3、可達性分析

上面咱們提到當引用強弱關係發生變化的時候，他的狀態會發生改變，那麼這個強弱關係是如何判斷的呢？
熟悉 JVM 的同窗應該知道判斷對象是否存活的算法大體有兩種；

1. 引用計數法，即每當有一個對象引用他的時候就加1，引用失效時減1，當任什麼時候候計數都爲0時，就表明對象能夠被回收了；
2. 可達性分析法，即從一組 GC Roots 對象出發，引用可達即表明存活，引用不可達就表明是可回收對象；如圖所示：

上圖僅表示了，強引用的回收，當加入了軟引用，弱引用和虛應用以後：

• 單路徑中，以最弱的引用爲準
• 多路徑中，以最強的引用爲準

已上圖爲例：

• 對於 Obj 1：單路徑可達，因此 GC Roots 到 Obj 1爲弱引用；
• 對於 Obj 5：多路徑可達，因此 GC Roots 到 Obj 5爲軟引用；

4、成員變量和構造函數

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：表示正在排隊等待入隊的引用；

5、重要函數

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 ；