「Java 進階之路」系列 Day35寫在前面前幾篇一直在講垃圾怎么回收標(biāo)記清除/整理/復(fù)制、分代收集、CMS/G1/ZGC但更前置的問題其實是JVM怎么判斷一個對象是不是垃圾很多人第一反應(yīng)是引用計數(shù)但Java壓根沒用這個方案還有人寫緩存時納悶——明明一個Map里還攥著對象的引用為什么內(nèi)存緊張時這些對象說沒就沒了。這篇把這兩個問題一次講清楚。一、是什么可達性分析怎么判斷一個對象活著還是死了為什么不用引用計數(shù)最直觀的判活方案是給每個對象掛一個計數(shù)器被引用一次加一引用失效減一計數(shù)器歸零就判定為垃圾——這就是引用計數(shù)法簡單直接但有一個硬傷處理不了循環(huán)引用。對象A持有對B的引用對象B持有對A的引用如果A和B互相引用即使外部所有代碼都不再持有A、B的引用了它們兩個的計數(shù)器依然都是1永遠不會歸零會被誤判為還活著造成內(nèi)存泄漏。正是因為這個致命缺陷主流JVM都沒有采用引用計數(shù)法Python等語言用了引用計數(shù)但要靠額外的循環(huán)檢測器來彌補這個漏洞?？蛇_性分析從根出發(fā)摸得到就是活的Java采用的方案是可達性分析Reachability Analysis選定一批特殊的對象作為GC Roots從這些Roots出發(fā)沿著引用鏈一路往下摸凡是能夠被摸到可達的對象都判定為存活摸不到的對象才判定為垃圾。GC Roots對象A對象B對象C對象D對象E對象F上圖里A、B、C、D、E都能從GC Roots出發(fā)摸到判定為存活F雖然自己引用著E但沒有任何Roots能摸到F本身F就是垃圾即使F和E之間有引用關(guān)系也無濟于事——這正好解決了引用計數(shù)法處理不了的循環(huán)引用問題即使F和E互相引用只要它們整體上摸不到GC Roots照樣會被正確回收。常見能作為GC Roots的對象包括各個線程當(dāng)前調(diào)用棧里的局部變量、方法區(qū)里的靜態(tài)變量、被JNINative方法引用的對象、以及一些和類加載、類型相關(guān)的固定引用。二、為什么明明有引用還是被回收強引用之外還有三種引用如果只有有引用就存活、沒引用就回收這一條規(guī)則會有一類場景很難處理想讓JVM在內(nèi)存充裕時盡量保留一批對象比如緩存但內(nèi)存緊張、快要OOM之前又希望能優(yōu)先把它們清掉而不是眼睜睜看著系統(tǒng)因為死抱著緩存不放而崩潰。Java用四種強度不同的引用類型來滿足這類需求引用類型什么時候被回收典型場景強引用Strong Reference只要還可達永遠不會被回收哪怕內(nèi)存溢出也不放日常的new Object()賦值軟引用SoftReference內(nèi)存足夠時不回收內(nèi)存不足、快要OOM之前會被回收內(nèi)存敏感的緩存弱引用WeakReference不管內(nèi)存夠不夠只要發(fā)生一次GC就會被回收ThreadLocal的Entry key虛引用PhantomReference形同虛設(shè)隨時可能被回收拿不到引用的對象本身只用來在對象被回收時收到一個通知配合Cleaner做資源清理跟蹤強引用 永遠不回收軟引用 內(nèi)存不足才回收弱引用 只要GC就回收虛引用 完全不影響生存 只用來收通知回到開頭的疑問如果緩存的Map里存的是軟引用而不是強引用即使這個引用鏈條一直存在、對象在可達性分析里依然可達只要JVM快要內(nèi)存不足了垃圾回收器依然會主動把軟引用指向的對象清掉把內(nèi)存騰出來——這不是可達性分析出了錯而是軟引用本身在設(shè)計上就允許JVM在特定條件下選擇性地把它們視為可以犧牲的對象。三、怎么用軟引用做緩存弱引用防內(nèi)存泄漏軟引用一個天然的、內(nèi)存敏感的緩存實現(xiàn)MapString,SoftReferencebyte[]cachenewHashMap();// 存入緩存cache.put(key1,newSoftReference(loadBigData()));// 取用時要判斷是否已經(jīng)被回收SoftReferencebyte[]refcache.get(key1);byte[]data(ref!null)?ref.get():null;if(datanull){dataloadBigData();// 已被回收重新加載cache.put(key1,newSoftReference(data));}用軟引用包一層緩存就能自動獲得內(nèi)存寬裕時盡量保留內(nèi)存緊張時自動讓路的能力不需要手寫LRU淘汰邏輯去猜測什么時候該清理——代價是每次取用都要判空重新加載且軟引用對象本身如果引用關(guān)系復(fù)雜也會帶來一定的額外管理開銷所以規(guī)模較小、訪問頻繁的緩存用現(xiàn)成的Guava Cache/Caffeine這類工具會比自己手搓軟引用更省心。弱引用ThreadLocal為什么用它做key回到Day09講過的ThreadLocal內(nèi)存泄漏問題——ThreadLocalMap的Entry對key也就是ThreadLocal實例本身用的就是弱引用只要一次GC發(fā)生只要沒有其他強引用指著這個ThreadLocal實例它就會被回收Entry里的key會自動變成null。這樣設(shè)計是為了讓外部代碼已經(jīng)不再持有這個ThreadLocal引用這件事能盡快被JVM感知到而不需要用戶顯式調(diào)用remove()才能讓key被回收——但value依然是強引用不會跟著自動清理這才是ThreadLocal真正的內(nèi)存泄漏風(fēng)險點key沒了、value還在占著位置出不去所以remove()該調(diào)用還是要調(diào)用。虛引用連拿到對象這件事都不允許虛引用是四種里最特殊的一種——通過PhantomReference.get()永遠返回null也就是說你壓根不能靠虛引用去訪問這個對象它唯一的作用是配合一個引用隊列ReferenceQueue在對象被垃圾回收器真正回收前的某個時機往隊列里塞一個通知。這給了開發(fā)者一個對象即將/已經(jīng)被回收的鉤子常用來替代已經(jīng)過時的finalize()方法做一些堆外內(nèi)存、文件句柄之類的資源清理收尾工作JDK 9之后的java.lang.ref.Cleaner底層就是基于虛引用實現(xiàn)的。四、面試追問Q1為什么Java不用引用計數(shù)法判斷對象是否存活引用計數(shù)法無法正確處理循環(huán)引用的場景兩個互相引用的對象即使外部已經(jīng)沒有任何代碼持有它們各自的計數(shù)器依然不為零永遠不會被判定為垃圾導(dǎo)致內(nèi)存泄漏。Java采用的可達性分析是從GC Roots出發(fā)摸引用鏈天然能正確處理循環(huán)引用——只要整體上摸不到GC Roots即使對象之間互相引用也會被回收。Q2哪些對象可以作為GC Roots常見的包括各線程當(dāng)前調(diào)用棧里的局部變量、方法區(qū)里的靜態(tài)變量、被JNINative方法引用的對象以及一些和類加載、類型信息相關(guān)的固定引用。可達性分析就是從這批對象出發(fā)判斷哪些對象能被引用鏈摸到。Q3軟引用和弱引用的核心區(qū)別是什么軟引用只有在內(nèi)存不足、即將發(fā)生OutOfMemoryError之前才會被回收內(nèi)存充裕時會盡量保留適合做內(nèi)存敏感的緩存弱引用則不管內(nèi)存夠不夠只要發(fā)生一次垃圾回收就會被清理生存周期比軟引用短得多典型應(yīng)用是ThreadLocalMap里Entry對key的引用。Q4ThreadLocal為什么會內(nèi)存泄漏跟弱引用有什么關(guān)系ThreadLocalMap的Entry對keyThreadLocal實例用的是弱引用只要沒有其他強引用一次GC后key就會被回收變成null但Entry對value的引用依然是強引用不會自動清理。如果線程是線程池里的核心線程、長期存活且用完ThreadLocal后沒有調(diào)用remove()這些key已經(jīng)為null、但value還在的Entry會一直占用內(nèi)存無法被回收這才是真正的內(nèi)存泄漏點不是弱引用本身導(dǎo)致的問題而是value沒有配套清理導(dǎo)致的。Q5虛引用有什么實際用途虛引用無法通過get()方法獲取到對象本身永遠返回null唯一作用是配合引用隊列在對象被垃圾回收前后收到一個通知。它常被用來替代已經(jīng)過時、不推薦使用的finalize()方法跟蹤對象生命周期的結(jié)束時機去做一些堆外內(nèi)存釋放、文件句柄關(guān)閉之類的資源清理工作JDK 9之后推薦的java.lang.ref.Cleaner底層就是基于虛引用實現(xiàn)的。下一篇預(yù)告Day36 結(jié)合線上實戰(zhàn)場景講講OOM排查和連接池問題該怎么定位——從這幾篇講的GC原理落地到真實的故障排查思路上。