JVM如何判斷哪些對(duì)象可以回收？
前言
我們上一篇分析的是JVM的內(nèi)存分布，分為堆內(nèi)存、虛擬機(jī)棧、本地方法棧、方法區(qū)以及程序計(jì)數(shù)器等主要區(qū)域;各個(gè)區(qū)域的特點(diǎn)我也就不啰嗦了，想看的給大家直通車：
大魚(yú)今天在家本來(lái)是閑暇的一天，很舒適，結(jié)果這個(gè)時(shí)候，媽媽敲門(mén)進(jìn)來(lái)我房間了，咨詢我有沒(méi)有時(shí)間幫忙打掃一下父母的房間;(沒(méi)有時(shí)間
當(dāng)然我不能這么說(shuō)了，我是個(gè)炒雞孝順的好孩子，當(dāng)然了，媽媽，當(dāng)然有時(shí)間了啊，now go，我的乖乖，這么亂的屋子，不對(duì)啊，平時(shí)都是很干凈的啊(內(nèi)心想逃，后悔，想拒絕
不對(duì)啊，媽，為什么房間這么亂啊，這有的東西我也不知道要不要扔掉啊，瞬間難到我了，你們生活中有沒(méi)有遇到過(guò)類似的煩惱?
或者有沒(méi)有遇到糾結(jié)一個(gè)東西要不要扔掉的時(shí)候，那時(shí)候你是如何做的呢?
我們知道在JVM內(nèi)存中，實(shí)例對(duì)象基本都是存在于堆中的，那總不能無(wú)期限的往里面放吧，一些用不著的對(duì)象就需要隨時(shí)回收掉，這樣才能保證這個(gè)內(nèi)存的均衡性，才能保證JVM的正常運(yùn)行
那么問(wèn)題來(lái)了，JVM如何知道哪些對(duì)象該回收、哪些不該回收，就像剛才大魚(yú)不知道爸媽房間哪些東西該收拾、哪些不該收拾一個(gè)道理的，其實(shí)在JVM中是有兩種解決辦法的，分別是引用計(jì)數(shù)法和可達(dá)性分析法兩種方法，來(lái)確定這些對(duì)象之中哪些是存活著的、哪些是已經(jīng)死去的(不可能再被任何途徑使用的對(duì)象)
問(wèn)題明白了，下面就是來(lái)解決這個(gè)問(wèn)題了，沖吧，干飯人
引用計(jì)數(shù)算法
這個(gè)其實(shí)很簡(jiǎn)單了，重點(diǎn)就是計(jì)數(shù);給對(duì)象添加一個(gè)引用計(jì)數(shù)器，每引用一次，計(jì)數(shù)器加一;引用失效的時(shí)候，計(jì)數(shù)器減一;當(dāng)計(jì)數(shù)器為0 的時(shí)候，則認(rèn)為不可能被再次使用了;
我覺(jué)得不需要大魚(yú)多解釋了應(yīng)該，這個(gè)應(yīng)該及其好理解，但是，這種方法存在一個(gè)致命的問(wèn)題：無(wú)法解決對(duì)象相互循環(huán)引用的問(wèn)題
解釋下這個(gè)循環(huán)引用問(wèn)題
一起來(lái)看看下面這個(gè)例子
- public class ReferenceCountingGC {
- public Object instance = null;
- private byte[] bigSize = new byte[2 * 1024 * 1024];
- public static void main(String[] args) {
- ReferenceCountingGC o1 = new ReferenceCountingGC();
- ReferenceCountingGC o2 = new ReferenceCountingGC();
- o1.instance = o2;
- o2.instance = o1;
- o1 = null;
- o2 = null;
- //假設(shè)在這行發(fā)生了GC，o1和o2是否被回收
- System.gc();
- }
上面例子中o1和o2對(duì)象都分別將對(duì)方作為自己的屬性注入，這也就是形成了所謂的循環(huán)引用;最后o1和o2對(duì)象都置為null，也就是棧中不再指向堆中的實(shí)例對(duì)象地址，但是他們還是會(huì)互相引用，所以不會(huì)被GC回收
再來(lái)看個(gè)圖解版，加深理解
剛new的o1和o2對(duì)象是這個(gè)樣子的：
分別引用了雙方之后是這樣子的狀態(tài)：
最后置為null變成這個(gè)樣子的：
是的，沒(méi)錯(cuò)，最后就變成了如上圖所示的尷尬境地，對(duì)象1和對(duì)象2在內(nèi)部互相引用，永遠(yuǎn)失效不了，導(dǎo)致GC通過(guò)引用計(jì)數(shù)法判斷他們的引用計(jì)數(shù)的時(shí)候，永遠(yuǎn)無(wú)法判斷為0，也就是無(wú)法回收咯，不就造成了內(nèi)存泄漏了嗎
可達(dá)性分析法
上面說(shuō)的引用計(jì)數(shù)法有缺點(diǎn)，而且這個(gè)問(wèn)題還不小，所以現(xiàn)在使用這種方式來(lái)作為判斷對(duì)象是否存活標(biāo)準(zhǔn)的比較少，多數(shù)使用的是另一種，可達(dá)性分析法;
先來(lái)解釋下可達(dá)性分析法
基本思路就是通過(guò)一系列的”GC Roots“的對(duì)象作為起始點(diǎn)，從這些節(jié)點(diǎn)開(kāi)始向下搜索，搜索所走過(guò)的路徑就是引用鏈，當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何的引用鏈可達(dá)的時(shí)候，則證明這個(gè)對(duì)象是不可用的
什么意思呢?來(lái)個(gè)白話文版本的，就是選擇一系列的基準(zhǔn)點(diǎn)，這個(gè)點(diǎn)能通過(guò)引用鏈連接到的對(duì)象就被認(rèn)為是可用的，只要是無(wú)法到達(dá)的，都被認(rèn)為是不可用的，這個(gè)不可用并不一定代表對(duì)象死亡，只代表對(duì)象無(wú)法觸達(dá)，無(wú)法再次引用
這就像遞歸定義的關(guān)系一樣，如果只定義了遞歸項(xiàng)而不定義初始項(xiàng)的話，關(guān)系也就無(wú)從成立，無(wú)從開(kāi)始;如果初始項(xiàng)定義漏掉了內(nèi)容的話，遞推的結(jié)果也會(huì)隨之而漏掉;
什么是GC Roots
垃圾回收時(shí)，JVM會(huì)首先找到所有的GC Roots，這個(gè)過(guò)程叫做枚舉根節(jié)點(diǎn)，這個(gè)過(guò)程需要暫停用戶線程，也就是stop the world;然后再?gòu)腉C Roots這些根節(jié)點(diǎn)向下搜索，可達(dá)的對(duì)象保留，不可達(dá)的便會(huì)回收掉
那么，到底什么是GC Roots呢?
GC Roots就是對(duì)象，就是JVM確定當(dāng)前絕對(duì)不能回收的對(duì)象，只有找到這種對(duì)象，后面的搜索才會(huì)有意義，不能被回收的對(duì)象所依賴的對(duì)象也就必然不能回收
GC Roots是一種特殊的對(duì)象，是Java程序在運(yùn)行過(guò)程中所必須的對(duì)象，而且必須是根對(duì)象
哪些對(duì)象可以作為GC Roots
基本可以作為GC Roots的對(duì)象基本分為兩大類：全局對(duì)象和執(zhí)行上下文;
全局對(duì)象
- 方法區(qū)靜態(tài)屬性引用的對(duì)象：全局對(duì)象的一種，Class對(duì)象本身很難被回收，回收的條件也是很苛刻，只要Class不被回收，靜態(tài)成員不會(huì)被回收
- 方法區(qū)常量池引用的對(duì)象：全局對(duì)象，比如字符串常量池，常量初始化之后不會(huì)再次改變
執(zhí)行上下文對(duì)象
- 方法棧的棧幀本地變量表引用的對(duì)象：線程方法執(zhí)行的時(shí)候，會(huì)將方法打包成一個(gè)棧幀入棧執(zhí)行，方法里得到的局部變量會(huì)存放到本地變量表中，只要方法未執(zhí)行完，還沒(méi)出棧，即本地變量表還會(huì)被訪問(wèn)，GC不應(yīng)該回收
- JNI本地方法棧引用的對(duì)象：和上面同樣的道理
- 被同步鎖持有的對(duì)象：被synchronized鎖住的對(duì)象不可回收，否則鎖就失效了，那鎖就沒(méi)意義了
不可達(dá)的對(duì)象一定會(huì)回收嗎?(緩刑階段)
其實(shí)被判定為 不可達(dá)的對(duì)象，也不一定是”非死不可“的，還有一次復(fù)活機(jī)會(huì)，這時(shí)是處于緩刑階段，要真正宣告一個(gè)對(duì)象死亡，至少要經(jīng)歷再次標(biāo)記過(guò)程(其實(shí)就是finalize方法在搞怪)
我們?cè)陔娨曋幸彩墙?jīng)常見(jiàn)到類似的場(chǎng)景，一個(gè)人被判定死刑了，午時(shí)已到，立即執(zhí)行，一般這個(gè)時(shí)候就會(huì)出來(lái)一個(gè)飛刀，刀下留人，皇上有旨;也有可能是一個(gè)飛刀，直接二話不說(shuō)，噼里啪啦一頓操作，把人救走，是不是很熟悉
沒(méi)錯(cuò)，這個(gè)過(guò)程就是finalize的內(nèi)部過(guò)程，讓被判定死刑的犯人”重獲新生“
標(biāo)記的前提是對(duì)象在進(jìn)行可達(dá)性分析后發(fā)現(xiàn)沒(méi)有與GC Roots相連接的引用鏈
第一次標(biāo)記
篩選的條件是這個(gè)對(duì)象是否有必要執(zhí)行finalize()方法;若對(duì)象未重寫(xiě)這個(gè)方法或者已被虛擬機(jī)調(diào)用過(guò)，虛擬機(jī)則認(rèn)為沒(méi)有必要執(zhí)行，對(duì)象被回收
第二次標(biāo)記
若這個(gè)對(duì)象有必要執(zhí)行finalize方法，則這個(gè)對(duì)象會(huì)被放到一個(gè)F-Queue隊(duì)列中，并在稍后由虛擬機(jī)自動(dòng)創(chuàng)建的一個(gè)低優(yōu)先級(jí)的finalizer線程去執(zhí)行;
這里的執(zhí)行指的是虛擬機(jī)會(huì)觸發(fā)這個(gè)方法，但是不保證運(yùn)行完成，這樣做的原因是這個(gè)方法執(zhí)行緩慢，也可能出現(xiàn)死循環(huán)，嚴(yán)重可能會(huì)導(dǎo)致回收系統(tǒng)崩潰
finalize是對(duì)象逃脫死亡命運(yùn)的最后一次機(jī)會(huì)，稍后GC會(huì)對(duì)F-Queue中的對(duì)象進(jìn)行二次標(biāo)記，如果在這里面重新和GC Roots掛上引用關(guān)系，則可以逃脫被回收的命運(yùn);否則，就肯定GG了
方法區(qū)的回收
很多人認(rèn)為方法區(qū)沒(méi)有垃圾回收，Java虛擬機(jī)規(guī)范中也確實(shí)說(shuō)過(guò)可以不要求虛擬機(jī)在方法區(qū)實(shí)現(xiàn)垃圾收集，而且在方法區(qū)中的垃圾回收的性價(jià)比一般比較低，在上面說(shuō)的堆中進(jìn)行一次垃圾回收會(huì)回收70—95的空間，而永久代中的垃圾回收的效率遠(yuǎn)低于此
方法區(qū)中的垃圾回收主要是兩部分：廢棄常量和無(wú)用的類;廢棄常量的回收和Java堆中的對(duì)象類似，不多說(shuō)了
但是判斷一個(gè)類是否是無(wú)用的類，則條件比較苛刻，需要滿足三個(gè)條件：
- 該類的所有實(shí)例都已經(jīng)被回收，即Java堆中無(wú)該類的任何實(shí)例
- 加載該類的ClassLoader已經(jīng)被回收
- 該類對(duì)應(yīng)的java.lang.Class對(duì)象沒(méi)有在任何地方被引用，無(wú)法在任何地方通過(guò)反射訪問(wèn)到該類的方法
虛擬機(jī)規(guī)范中說(shuō)的是滿足上面三個(gè)條件，便可以對(duì)無(wú)用的類進(jìn)行回收，但是并不是必然回收;是否對(duì)類對(duì)類進(jìn)行回收，可以根據(jù)虛擬機(jī)提供的參數(shù)來(lái)進(jìn)行控制
在大量使用反射、動(dòng)態(tài)代理、CGLib等ByteCode框架、動(dòng)態(tài)生成JSP以及OSGI這類頻繁自定義ClassLoader的場(chǎng)景都需要虛擬機(jī)具備類的卸載功能，以保證永久代不會(huì)溢出
我愛(ài)總結(jié)
我愛(ài)總結(jié)之JVM如何判斷哪些對(duì)象可以回收，總結(jié)很重要，整理思路，記得后續(xù)的溫故而知新，GitHub地址在下面，我會(huì)把所有原創(chuàng)技術(shù)文章放到上面，持續(xù)不斷的更新
引用計(jì)數(shù)法：存在循環(huán)引用的致命問(wèn)題
可達(dá)性分析法：以GC Roots作為起點(diǎn)，可以達(dá)到的就不可回收，不可達(dá)到的暫定認(rèn)為”死亡“;但是不是非死不可，有通過(guò)finalize方法加重新連接引用鏈的方法，讓一個(gè)對(duì)象重新復(fù)活;但是不保證執(zhí)行完成，這種方法是不靠譜的，也是不建議使用的
好了，以上就是全部?jī)?nèi)容了，我是小魚(yú)仙，你們的學(xué)習(xí)成長(zhǎng)小伙伴
我希望有一天能夠靠寫(xiě)字養(yǎng)活自己，現(xiàn)在還在磨練，這個(gè)時(shí)間可能會(huì)有很多年，感謝你們做我最初的讀者和傳播者。請(qǐng)大家相信，只要給我一份愛(ài)，我終究會(huì)還你們一頁(yè)情的。
