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?Bitsstatic?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 。