四大引用各自回收條件？獲取對(duì)象方式爬橡？觸發(fā)OOM概率治唤？
回答這個(gè)問(wèn)題的最好方式就是編碼驗(yàn)證。
本文代碼運(yùn)行環(huán)境：Mac os + jdk se 8 + VM options (-Xms10m -Xmx10m)
被測(cè)試對(duì)象類(lèi)RefTestObj
RefTestObj定義了三個(gè)成員變量糙申，重寫(xiě)了toString和finalize方法宾添。
測(cè)試OOM
測(cè)試代碼：使用不同引用類(lèi)型循環(huán)創(chuàng)建10w個(gè)RefTestObj對(duì)象，測(cè)試其發(fā)生OOM概率柜裸。
- 強(qiáng)引用：調(diào)用 refTestOOM(0) 缕陕，大概在創(chuàng)建1.5w個(gè)對(duì)象時(shí)出現(xiàn)OOM，在此之前沒(méi)有打印過(guò)任何finalize方法日志疙挺。
- 軟引用：調(diào)用 refTestOOM(1) 扛邑，順利創(chuàng)建完所有對(duì)象。 期間控制臺(tái)有幾次（大量對(duì)象的）finalize方法日志輸出铐然。
- 弱引用：調(diào)用tefTestOOM(2) 蔬崩，順利創(chuàng)建完所有對(duì)象欢峰。 期間控制臺(tái)基本都在打印finalize方法日志铐刘。
- 虛引用：調(diào)用refTestOOM(3) 几于，大概在創(chuàng)建3w個(gè)對(duì)象時(shí)出現(xiàn)OOM讳侨，在此之前有打印過(guò)finalize方法日志陷寝。
- 細(xì)心的讀者可能已經(jīng)發(fā)現(xiàn)測(cè)試代碼中124行薄湿，做了100ms延時(shí)操作艇抠。如果沒(méi)有這個(gè)延時(shí)妒御，軟引用和弱引用也會(huì)出現(xiàn)OOM樟氢，原因請(qǐng)看代碼注釋和下一個(gè)問(wèn)題冈绊。
測(cè)試結(jié)果
| 引用類(lèi)型 | 回收條件 | 獲取對(duì)象方式 | 觸發(fā)OOM概率 |
|---|---|---|---|
| 強(qiáng)引用 | 不回收 | 通過(guò)引用 | 高 |
| 軟引用 | 內(nèi)存緊張時(shí) | get方法 | 低 |
| 弱引用 | GC時(shí) | get方法 | 很低 |
| 虛引用 | 不確定？ | 無(wú)法獲取 | 較高埠啃？ |
- StrongRef 直到OOM也不回收其引用的對(duì)象死宣。 通過(guò)引用直接獲取目標(biāo)對(duì)象實(shí)例。
- SoftRef 內(nèi)存吃緊時(shí)回收其引用的對(duì)象碴开。 通過(guò)get方法獲取對(duì)象引用毅该，可能為null。 不會(huì)觸發(fā)OOM(如果沒(méi)時(shí)間釋放內(nèi)存也會(huì)觸發(fā)OOM(比如創(chuàng)建對(duì)象太快))
- WeakRef GC時(shí)觸發(fā)回收潦牛。 get方法獲取對(duì)象引用眶掌，可能為null。 不會(huì)觸發(fā)OOM巴碗。(如果沒(méi)時(shí)間釋放內(nèi)存也會(huì)觸發(fā)OOM(比如創(chuàng)建對(duì)象太快)) 朴爬。 較SoftRef 對(duì)象執(zhí)行finalize更頻繁，極端情況出現(xiàn)OOM概率也更低橡淆。
- PhantomRef 回收條件：不確定召噩，看日志有執(zhí)行finalize函數(shù)。 無(wú)法獲取對(duì)象實(shí)例逸爵。 會(huì)觸發(fā)OOM（較SoftRef和WeakRef概率高, 感覺(jué)和StrongRef差不多）具滴。
為什么使用了WeakRef（SoftRef）也會(huì)觸發(fā)OOM？
- 創(chuàng)建對(duì)象時(shí)师倔，需要在堆中申請(qǐng)內(nèi)存抵蚊，如果申請(qǐng)時(shí)內(nèi)存不夠就會(huì)觸發(fā)OOM。
- JVM根據(jù)算法在整理和釋放對(duì)象(沒(méi)有使用的)內(nèi)存溯革，而且這兩個(gè)過(guò)程不是同步的贞绳。
對(duì)象的finalize方法什么時(shí)候被執(zhí)行？ 什么時(shí)候被放入ReferenceQueue中的致稀？
公用測(cè)試代碼 referenceQueueMonitor ：用于監(jiān)控ReferenceQueue中對(duì)象冈闭，如果有則取出并打印日志。
測(cè)試弱引用 testWeakReferenceQueue
運(yùn)行日志
結(jié)果分析
- 弱引用在GC觸發(fā)后就回收對(duì)象抖单。
- GC后其指向的對(duì)象會(huì)被加入關(guān)聯(lián)的ReferenceQueue萎攒，和執(zhí)行對(duì)象的finalize方法遇八。
- 關(guān)于finalize方法調(diào)用：1. 由JVM調(diào)用，時(shí)機(jī)不確定耍休， 2. 最多只調(diào)用一次刃永。
測(cè)試軟引用 testSoftReferenceQueue
運(yùn)行日志
結(jié)果分析
- 從日志可以看到，通過(guò)19次gc后軟引用指向的對(duì)象終于被清理了羊精。（每多一次gc斯够，就會(huì)多創(chuàng)建1000個(gè)對(duì)象，以此來(lái)模擬內(nèi)存吃緊的情況喧锦。）
- 軟引用指向?qū)ο髸?huì)在內(nèi)存接近滿負(fù)荷時(shí)读规，垃圾回收器將會(huì)清理該對(duì)象；可能還會(huì)根據(jù)SoftReference.get()方法的調(diào)用情況(比如很長(zhǎng)時(shí)間未調(diào)用)來(lái)決定要不要回收燃少。
- 從日志來(lái)看軟引用在執(zhí)行對(duì)象的 finalize 方法之前被加入了 ReferenceQueue束亏；但實(shí)際上這兩個(gè)是相互獨(dú)立的邏輯，可參看下文
源碼分析章節(jié)阵具。
測(cè)試虛引用 testPhantomReferenceQueue
運(yùn)行日志
結(jié)果分析
- 虛引用在GC觸發(fā)后 , 直接調(diào)用了 finalize() 方法 , 但不會(huì)立即將其加入回收隊(duì)列 .
- 只有在真正對(duì)象被 GC 清除時(shí) , 才會(huì)將其加入 ReferenceQueue 隊(duì)列中去 .
- 對(duì)于虛引用對(duì)象碍遍，到底在經(jīng)過(guò)多次 GC 之后， 才會(huì)加入到隊(duì)列中去呢阳液？ （經(jīng)過(guò)測(cè)試怕敬，發(fā)現(xiàn)在二次GC后會(huì)將其加入隊(duì)列；關(guān)于什么時(shí)機(jī)將對(duì)象加入隊(duì)列趁舀，各個(gè)虛擬機(jī)實(shí)現(xiàn)應(yīng)該是有差異的赖捌。）
以上只是帶著問(wèn)題并通過(guò)編碼來(lái)驗(yàn)證的過(guò)程，如果想搞清楚答案為什么是這樣而不是那樣矮烹，就需要翻一翻jdk相關(guān)的代碼了越庇。
源碼實(shí)現(xiàn)
對(duì)象是怎么被加入ReferenceQueue的？
在java.lang.ref.Reference類(lèi)中定義有下圖所示的一段靜態(tài)代碼奉狈。
由上圖代碼可以看出卤唉，在Reference類(lèi)裝載時(shí)就會(huì)啟動(dòng)一個(gè)名叫ReferenceHandler的高優(yōu)先級(jí)的守護(hù)線程。ShareSecrets類(lèi)相關(guān)邏輯先忽略仁期，我們繼續(xù)看看ReferenceHandler線程類(lèi)的定義桑驱。
重點(diǎn)關(guān)注run方法□说埃可以看到一個(gè)無(wú)限循環(huán)邏輯在執(zhí)行tryHandlePending(true)方法熬的，在看tryHandlePending方法代碼前，我們先看下Reference類(lèi)中定義的幾個(gè)變量赊级。(因?yàn)樗鼈兒苤匾嚎颍脖阌诤罄m(xù)代碼理解)
簡(jiǎn)單說(shuō)下，
- 變量
referent-> 對(duì)象引用實(shí)例理逊。 - 變量
queue-> 該引用類(lèi)型關(guān)聯(lián)的ReferenceQueue實(shí)例橡伞，它本身并不是一個(gè)隊(duì)列結(jié)構(gòu)實(shí)現(xiàn)盒揉。 - 變量
next-> 對(duì)象入隊(duì)后用此變量來(lái)維護(hù)一個(gè)鏈表結(jié)構(gòu)。 - 變量
discovered和pending為Reference類(lèi)型兑徘，均有VM調(diào)用并賦值刚盈。 - 變量
lock同步鎖對(duì)象。我理解是VM檢測(cè)到有待處理對(duì)象時(shí)會(huì)通過(guò)此對(duì)象喚醒ReferenceHandler線程挂脑。
下面再來(lái)看看 tryHandlePending 方法實(shí)現(xiàn)藕漱。
方法主要邏輯：獲取對(duì)象鎖并判斷 pending 變量是否為null？
- 為null：根據(jù)參數(shù)waitForNotify 決定是 wait 還是繼續(xù)循環(huán)執(zhí)行最域。
- 不為null：進(jìn)行賦值谴分，并判斷如果不是Cleaner對(duì)象則將其放入隊(duì)列中锈麸。
到這里镀脂，關(guān)于Reference對(duì)象如何被放入隊(duì)列的代碼邏輯就分析完了。前面我有提到說(shuō)java.lang.ref.ReferenceQueue類(lèi)并不是一個(gè)隊(duì)列忘伞，那我們看看其 enqueue(r) 方法是如何實(shí)現(xiàn)的薄翅？
其實(shí)它是使用自定義的一個(gè) head 變量和Reference類(lèi)的 next 變量來(lái)實(shí)現(xiàn)的隊(duì)列效果。
這里也有l(wèi)ock鎖對(duì)象氓奈，最后一句代碼還執(zhí)行了notifyAll()翘魄，原因就是該類(lèi)對(duì)外提供了一個(gè)阻塞 remove 方法，調(diào)用notifyAll()可喚醒在該鎖上等待的線程舀奶，具體代碼就不貼了暑竟，感興趣的讀者請(qǐng)自行查閱。
對(duì)象的 finalize()方法執(zhí)行邏輯育勺？
在java.lang.ref.Finalizer類(lèi)中定義有如下代碼但荤，可以看出FinalizerThread線程在類(lèi)裝載時(shí)就被啟動(dòng)了。
FinalizerThread 線程主要邏輯就是從引用隊(duì)列 queue 中取出Finalizer對(duì)象涧至，并執(zhí)行其 runFinalizer()方法腹躁。
注意：這里的 queue 是Finalizer類(lèi)中定義的靜態(tài)變量和我們創(chuàng)建引用對(duì)象傳入的queue不是同一個(gè)哦。
繼續(xù)跟進(jìn) runFinalizer方法 ~
上圖中第 97 行代碼 remove 方法主要是將當(dāng)前Finalizer引用(對(duì)象)從鏈表中移除南蓬；第101 纺非、102 行代碼可看出只要其關(guān)聯(lián)的 目標(biāo)對(duì)象 不為null且不是枚舉類(lèi)型，則執(zhí)行其finalize()方法赘方；第 109 行代碼調(diào)用了 super.clear() 方法將目標(biāo)對(duì)象引用置為null烧颖，已防止重復(fù)執(zhí)行finalize方法。
虛引用(PhantomReference) 存在的意義和使用場(chǎng)景是窄陡？
這個(gè)不常用炕淮，可參看其子類(lèi)sun.misc.Cleaner。
參考文中測(cè)試代碼泳梆？傳送門(mén)~
由于水平有限鳖悠，文中錯(cuò)誤之處難免榜掌，發(fā)現(xiàn)問(wèn)題還望指出；如果你對(duì)文中觀點(diǎn)有不同看法請(qǐng)留言告訴我乘综，謝謝憎账。
