對於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 的處理流程相當於事件處理
- 如果 new Reference 的時候如果沒有傳入 ReferenceQueue，相當於使用 JVM 的默認處理流程，達到一定條件的時候由GC回收；
- 如果 new Reference 的時候傳入了 ReferenceQueue，相當於使用自定義的事件處理流程，此時的 ReferenceQueue 相當於事件監聽器，Reference 則相當於每個事件，GC 標記的時候添加 discovered鏈表 相當於事件發現過程，pending和enqueued則相當於注冊事件的過程，最后需要用戶自定義事件處理邏輯；
在 Reference 的生命周期里面，一共有四個狀態：
- Active：每個引用的創建之初都是活動狀態，直到下次 GC 的時候引用的強弱關系發生變化，同時不同的引用根據不同的策略改變狀態；
- Pending：正准備加入引用鏈表；
- Enqueued：已經加入引用鏈表，相當於已經注冊成功等待處理；
- Inactive：所有的引用對象的終點，可回收狀態；
三、可達性分析
上面我們提到當引用強弱關系發生變化的時候，他的狀態會發生改變，那么這個強弱關系是如何判斷的呢？
熟悉 JVM 的同學應該知道判斷對象是否存活的算法大致有兩種；
- 引用計數法，即每當有一個對象引用他的時候就加1，引用失效時減1，當任何時候計數都為0時，就代表對象可以被回收了；
- 可達性分析法，即從一組 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 ；