JVM如何判斷哪些對象可以回收？

當(dāng)然我不能這么說了，我是個炒雞孝順的好孩子，當(dāng)然了，媽媽，當(dāng)然有時間了啊，now go，我的乖乖，這么亂的屋子，不對啊，平時都是很干凈的?。▋?nèi)心想逃，后悔，想拒絕

不對啊，媽，為什么房間這么亂啊，這有的東西我也不知道要不要扔掉啊，瞬間難到我了，你們生活中有沒有遇到過類似的煩惱？

或者有沒有遇到糾結(jié)一個東西要不要扔掉的時候，那時候你是如何做的呢？

我們知道在JVM內(nèi)存中，實例對象基本都是存在于堆中的，那總不能無期限的往里面放吧，一些用不著的對象就需要隨時回收掉，這樣才能保證這個內(nèi)存的均衡性，才能保證JVM的正常運行

那么問題來了，JVM如何知道哪些對象該回收、哪些不該回收，就像剛才大魚不知道爸媽房間哪些東西該收拾、哪些不該收拾一個道理的，其實在JVM中是有兩種解決辦法的，分別是引用計數(shù)法和可達性分析法兩種方法，來確定這些對象之中哪些是存活著的、哪些是已經(jīng)死去的（不可能再被任何途徑使用的對象）

問題明白了，下面就是來解決這個問題了，沖吧，干飯人

解釋下這個循環(huán)引用問題

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();
    }

再來看個圖解版，加深理解

上面說的引用計數(shù)法有缺點，而且這個問題還不小，所以現(xiàn)在使用這種方式來作為判斷對象是否存活標(biāo)準(zhǔn)的比較少，多數(shù)使用的是另一種，可達性分析法；

先來解釋下可達性分析法

基本思路就是通過一系列的”GC Roots“的對象作為起始點，從這些節(jié)點開始向下搜索，搜索所走過的路徑就是引用鏈，當(dāng)一個對象到GC Roots沒有任何的引用鏈可達的時候，則證明這個對象是不可用的

什么意思呢？來個白話文版本的，就是選擇一系列的基準(zhǔn)點，這個點能通過引用鏈連接到的對象就被認(rèn)為是可用的，只要是無法到達的，都被認(rèn)為是不可用的，這個不可用并不一定代表對象死亡，只代表對象無法觸達，無法再次引用

這就像遞歸定義的關(guān)系一樣，如果只定義了遞歸項而不定義初始項的話，關(guān)系也就無從成立，無從開始；如果初始項定義漏掉了內(nèi)容的話，遞推的結(jié)果也會隨之而漏掉； 

什么是GC Roots

垃圾回收時，JVM會首先找到所有的GC Roots，這個過程叫做枚舉根節(jié)點，這個過程需要暫停用戶線程，也就是stop the world；然后再從GC Roots這些根節(jié)點向下搜索，可達的對象保留，不可達的便會回收掉

那么，到底什么是GC Roots呢？

GC Roots就是對象，就是JVM確定當(dāng)前絕對不能回收的對象，只有找到這種對象，后面的搜索才會有意義，不能被回收的對象所依賴的對象也就必然不能回收

GC Roots是一種特殊的對象，是Java程序在運行過程中所必須的對象，而且必須是根對象

哪些對象可以作為GC Roots

基本可以作為GC Roots的對象基本分為兩大類：全局對象和執(zhí)行上下文；

全局對象

• 方法區(qū)靜態(tài)屬性引用的對象：全局對象的一種，Class對象本身很難被回收，回收的條件也是很苛刻，只要Class不被回收，靜態(tài)成員不會被回收

• 方法區(qū)常量池引用的對象：全局對象，比如字符串常量池，常量初始化之后不會再次改變

執(zhí)行上下文對象

• 方法棧的棧幀本地變量表引用的對象：線程方法執(zhí)行的時候，會將方法打包成一個棧幀入棧執(zhí)行，方法里得到的局部變量會存放到本地變量表中，只要方法未執(zhí)行完，還沒出棧，即本地變量表還會被訪問，GC不應(yīng)該回收

• JNI本地方法棧引用的對象：和上面同樣的道理

• 被同步鎖持有的對象：被synchronized鎖住的對象不可回收，否則鎖就失效了，那鎖就沒意義了

不可達的對象一定會回收嗎？（緩刑階段）

其實被判定為 不可達的對象，也不一定是”非死不可“的，還有一次復(fù)活機會，這時是處于緩刑階段，要真正宣告一個對象死亡，至少要經(jīng)歷再次標(biāo)記過程（其實就是finalize方法在搞怪）

我們在電視中也是經(jīng)常見到類似的場景，一個人被判定死刑了，午時已到，立即執(zhí)行，一般這個時候就會出來一個飛刀，刀下留人，皇上有旨；也有可能是一個飛刀，直接二話不說，噼里啪啦一頓操作，把人救走，是不是很熟悉

沒錯，這個過程就是finalize的內(nèi)部過程，讓被判定死刑的犯人”重獲新生“

標(biāo)記的前提是對象在進行可達性分析后發(fā)現(xiàn)沒有與GC Roots相連接的引用鏈

第一次標(biāo)記

篩選的條件是這個對象是否有必要執(zhí)行finalize()方法；若對象未重寫這個方法或者已被虛擬機調(diào)用過，虛擬機則認(rèn)為沒有必要執(zhí)行，對象被回收

第二次標(biāo)記

若這個對象有必要執(zhí)行finalize方法，則這個對象會被放到一個F-Queue隊列中，并在稍后由虛擬機自動創(chuàng)建的一個低優(yōu)先級的finalizer線程去執(zhí)行；

這里的執(zhí)行指的是虛擬機會觸發(fā)這個方法，但是不保證運行完成，這樣做的原因是這個方法執(zhí)行緩慢，也可能出現(xiàn)死循環(huán)，嚴(yán)重可能會導(dǎo)致回收系統(tǒng)崩潰

finalize是對象逃脫死亡命運的最后一次機會，稍后GC會對F-Queue中的對象進行二次標(biāo)記，如果在這里面重新和GC Roots掛上引用關(guān)系，則可以逃脫被回收的命運；否則，就肯定GG了

很多人認(rèn)為方法區(qū)沒有垃圾回收，Java虛擬機規(guī)范中也確實說過可以不要求虛擬機在方法區(qū)實現(xiàn)垃圾收集，而且在方法區(qū)中的垃圾回收的性價比一般比較低，在上面說的堆中進行一次垃圾回收會回收70—95的空間，而永久代中的垃圾回收的效率遠低于此

方法區(qū)中的垃圾回收主要是兩部分：廢棄常量和無用的類；廢棄常量的回收和Java堆中的對象類似，不多說了

但是判斷一個類是否是無用的類，則條件比較苛刻，需要滿足三個條件：

• 該類的所有實例都已經(jīng)被回收，即Java堆中無該類的任何實例

• 加載該類的ClassLoader已經(jīng)被回收

• 該類對應(yīng)的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問到該類的方法

虛擬機規(guī)范中說的是滿足上面三個條件，便可以對無用的類進行回收，但是并不是必然回收；是否對類對類進行回收，可以根據(jù)虛擬機提供的參數(shù)來進行控制

在大量使用反射、動態(tài)代理、CGLib等ByteCode框架、動態(tài)生成JSP以及OSGI這類頻繁自定義ClassLoader的場景都需要虛擬機具備類的卸載功能，以保證永久代不會溢出

我愛總結(jié)之JVM如何判斷哪些對象可以回收，總結(jié)很重要，整理思路，記得后續(xù)的溫故而知新，GitHub地址在下面，我會把所有原創(chuàng)技術(shù)文章放到上面，持續(xù)不斷的更新

• 引用計數(shù)法：存在循環(huán)引用的致命問題

• 可達性分析法：以GC Roots作為起點，可以達到的就不可回收，不可達到的暫定認(rèn)為”死亡“；但是不是非死不可，有通過finalize方法加重新連接引用鏈的方法，讓一個對象重新復(fù)活；但是不保證執(zhí)行完成，這種方法是不靠譜的，也是不建議使用的