真实的国产乱ⅩXXX66竹夫人,五月香六月婷婷激情综合,亚洲日本VA一区二区三区,亚洲精品一区二区三区麻豆

成都創(chuàng)新互聯(lián)網(wǎng)站制作重慶分公司

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

對(duì)于Reference類大家可能會(huì)比較陌生，平時(shí)用的也比較少，對(duì)他的印象可能僅停在面試的時(shí)候查看引用相關(guān)的知識(shí)點(diǎn)；但在仔細(xì)查看源碼后發(fā)現(xiàn)Reference還是非常實(shí)用的，平時(shí)我們使用的類都是強(qiáng)引用的，它的回收完全依賴于 GC；但是對(duì)于有些類我們想要自己控制的時(shí)候就比較麻煩，比如我想在內(nèi)存還足夠的時(shí)候就保留，不夠的時(shí)候就回收，這時(shí)使用Reference就能夠十分靈活的控制類的存亡了。

站在用戶的角度思考問題，與客戶深入溝通，找到正鑲白網(wǎng)站設(shè)計(jì)與正鑲白網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：網(wǎng)站設(shè)計(jì)制作、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、申請(qǐng)域名、網(wǎng)站空間、企業(yè)郵箱。業(yè)務(wù)覆蓋正鑲白地區(qū)。

一、類定義

JDK源碼分析（7）之 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?{}

從注釋和類圖中可以清楚的看到：

  • Reference類是直接配合GC操作的，所以不能直接子類化，但是可以繼承Reference的子類；

  • Reference類定義了子類的主要邏輯，所以在SoftReference、WeakReference和PhantomReference中幾乎完全復(fù)用了Reference的邏輯；

二、Reference 框架結(jié)構(gòu)

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

如圖所示，Reference 的處理流程相當(dāng)于事件處理

  1. 如果 new Reference 的時(shí)候如果沒有傳入 ReferenceQueue，相當(dāng)于使用 JVM 的默認(rèn)處理流程，達(dá)到一定條件的時(shí)候由GC回收；

  2. 如果 new Reference 的時(shí)候傳入了 ReferenceQueue，相當(dāng)于使用自定義的事件處理流程，此時(shí)的?ReferenceQueue 相當(dāng)于事件監(jiān)聽器，Reference 則相當(dāng)于每個(gè)事件，GC 標(biāo)記的時(shí)候添加 discovered鏈表 相當(dāng)于事件發(fā)現(xiàn)過程，pending和enqueued則相當(dāng)于注冊(cè)事件的過程，最后需要用戶自定義事件處理邏輯；

在 Reference 的生命周期里面，一共有四個(gè)狀態(tài)：

  • Active：每個(gè)引用的創(chuàng)建之初都是活動(dòng)狀態(tài)，直到下次 GC 的時(shí)候引用的強(qiáng)弱關(guān)系發(fā)生變化，同時(shí)不同的引用根據(jù)不同的策略改變狀態(tài)；

  • Pending：正準(zhǔn)備加入引用鏈表；

  • Enqueued：已經(jīng)加入引用鏈表，相當(dāng)于已經(jīng)注冊(cè)成功等待處理；

  • Inactive：所有的引用對(duì)象的終點(diǎn)，可回收狀態(tài)；

三、可達(dá)性分析

上面我們提到當(dāng)引用強(qiáng)弱關(guān)系發(fā)生變化的時(shí)候，他的狀態(tài)會(huì)發(fā)生改變，那么這個(gè)強(qiáng)弱關(guān)系是如何判斷的呢？
熟悉 JVM 的同學(xué)應(yīng)該知道判斷對(duì)象是否存活的算法大致有兩種；

  1. 引用計(jì)數(shù)法，即每當(dāng)有一個(gè)對(duì)象引用他的時(shí)候就加1，引用失效時(shí)減1，當(dāng)任何時(shí)候計(jì)數(shù)都為0時(shí)，就代表對(duì)象可以被回收了；

  2. 可達(dá)性分析法，即從一組?GC Roots?對(duì)象出發(fā)，引用可達(dá)即代表存活，引用不可達(dá)就代表是可回收對(duì)象；如圖所示：

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

上圖僅表示了，強(qiáng)引用的回收，當(dāng)加入了軟引用，弱引用和虛應(yīng)用之后：

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

  • 單路徑中，以最弱的引用為準(zhǔn)

  • 多路徑中，以最強(qiáng)的引用為準(zhǔn)

已上圖為例：

  • 對(duì)于 Obj 1：單路徑可達(dá)，所以 GC Roots 到 Obj 1為弱引用；

  • 對(duì)于 Obj 5：多路徑可達(dá)，所以 GC Roots 到 Obj 5為軟引用；

四、成員變量和構(gòu)造函數(shù)

private?T?referent;?/*?Treated?specially?by?GC?*/volatile?ReferenceQueue?queue;volatile?Reference?next;transient?private?Reference?discovered;?/*?used?by?VM?*/private?static?Reference?pending?=?null;

Reference(T?referent)?{??this(referent,?null);
}

Reference(T?referent,?ReferenceQueue?queue)?{??this.referent?=?referent;??this.queue?=?(queue?==?null)???ReferenceQueue.NULL?:?queue;
}
  • referent：引用指向的對(duì)象，即需要Reference包裝的對(duì)象；
  • queue：雖然ReferenceQueue的名字里面有隊(duì)列，但是它的內(nèi)部卻沒有包含任何隊(duì)列和鏈表的結(jié)構(gòu)；他的內(nèi)部封裝了單向鏈表的添加，刪除和遍歷等操作，實(shí)際作用相當(dāng)于事件監(jiān)聽器；
  • next：引用單向鏈表；
  • discovered：discovered單向鏈表，由 JVM 維護(hù)；在 GC 標(biāo)記的時(shí)候，當(dāng)引用強(qiáng)弱關(guān)系達(dá)到一定條件時(shí)，由 JVM 添加；需要注意的是這個(gè)字段是 transient 修飾的，但是 Reference 類聲明的時(shí)候卻沒有實(shí)現(xiàn) Serializable 接口，這是因?yàn)?Reference 子類的子類可能實(shí)現(xiàn) Serializable 接口，另外一般情況下也不建議實(shí)現(xiàn) Serializable 接口；
  • pending：表示正在排隊(duì)等待入隊(duì)的引用；
五、重要函數(shù)
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);
????}
??});
}
可以看到在初始化的時(shí)候首先得到了層級(jí)最高的線程組即?System線程組，然后在里面加入了一個(gè)名為 “Reference Handler” 的?優(yōu)先級(jí)最高?的 ReferenceHandler 線程；
接下來的一段代碼是用于保證 JVM 在拋出 OOM 之前，原子性的清除非強(qiáng)引用的所有引用，如果空間仍然不足才會(huì)拋出 OOM；其中?SharedSecrets用于訪問類的私有變量，于反射不同的是，它不會(huì)創(chuàng)建新的對(duì)象；比如：
package?java.nio;//?Class?Bitsstatic?void?reserveMemory(long?size,?int?cap)?{
??...??//?optimist!
??if?(tryReserveMemory(size,?cap))?{????return;
??}??
??//?走到這里就說明空間已經(jīng)不足了
??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;
???}
??}
??...
}
有關(guān) “Reference Handler” 的線程信息可以使用jstack [] 抓取棧信息查看：
"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);
????}
??}
}
可以看到這個(gè)線程只做了一件很簡單的事情：
  • 首先確保InterruptedException和Cleaner已經(jīng)加載，關(guān)于Cleaner就是一個(gè)虛引用的實(shí)際應(yīng)用，后面還會(huì)詳細(xì)講到；
  • 然后死循環(huán)執(zhí)行tryHandlePending；
3. tryHandlePending 核心方法
/**
?*?Try?handle?pending?{@link?Reference}?if?there?is?one.

?*?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?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?q?=?r.queue;??if?(q?!=?ReferenceQueue.NULL)?q.enqueue(r);??return?true;
}
這個(gè)方法主要完成了discovered -> pending -> enqueued的整個(gè)入隊(duì)注冊(cè)流程；值得注意的是雖然Cleaner是虛引用，但是它并不會(huì)入隊(duì)，而是直接執(zhí)行clean操作，也就意味著在使用Cleaner的時(shí)候不需要在起一個(gè)線程監(jiān)聽ReferenceQueue了；
4. ReferenceQueue 概覽
static?ReferenceQueue?NULL?=?new?Null<>();//?用于標(biāo)記是否已經(jīng)入隊(duì)，防止重復(fù)入隊(duì)static?ReferenceQueue?ENQUEUED?=?new?Null<>();private?volatile?Reference?head?=?null;private?long?queueLength?=?0;//?reference入隊(duì)操作boolean?enqueue(Reference?r)?{?/*?Called?only?by?Reference?class?*///?poll?移除reference鏈表頭元素public?Reference?poll()?{?}//?移除reference鏈表下一個(gè)元素public?Reference?remove(long?timeout)?{?}public?Reference?remove()?throws?InterruptedException?{?}void?forEach(Consumer>?action)?{?}
從上面的代碼也可以看出ReferenceQueue的確沒有包含任何鏈表或者隊(duì)列的結(jié)構(gòu)，但是封裝了單向的鏈表的操作；
總結(jié)
  • Reference 主要用于更加靈活的控制對(duì)象的生死，其實(shí)現(xiàn)類似于事件處理，可以是 JVM 默認(rèn)處理，也可以是用戶自定義的處理邏輯；
  • 在 Java 語言中 Reference 類定義了子類（SoftReference，WeakReference，PhantomReference）的主要邏輯，但是判斷引用回收的條件主要在 JVM 中定義（主要發(fā)生在 GC 標(biāo)記階段），如果你有興趣可以到 OpenJDK 里面繼續(xù)深入研究；
  • 如果在使用 Reference 的時(shí)候傳入了 ReferenceQueue，即使用自定義的邏輯處理，那么最后一定要把 ReferenceQueue 中注冊(cè)的 Reference 移除，因?yàn)榇藭r(shí) GC 不會(huì)回收 ReferenceQueue 中的鏈表；
  • Reference Handler 線程只有一個(gè)，但是 Reference 鏈表卻有很多條（所以在注冊(cè)的時(shí)候需要加鎖），另外每個(gè) Class 對(duì)象都能同時(shí)生成多個(gè)引用對(duì)象，并注冊(cè) ReferenceQueue 。
            
            
                        

            文章名稱：JDK源碼分析（7）之Reference框架概覽            

            文章來源：http://weahome.cn/article/iipsge.html
        
    






    

        

            
                
                
在線咨詢

            
        

    

    

        
微信咨詢

        

    

    

        
電話咨詢

        

            
028-86922220（工作日）

            
18980820575（7×24）

        

    

    

        

            
                
提交需求

            
        

    

    

        

            
                
返回頂部