垃圾回收算法

1.垃圾回收需要做什么

Java垃圾回收器需要做的三件事：

1、哪些內(nèi)存需要回收？即如何判斷對(duì)象已經(jīng)死亡；

2、什么時(shí)候回收？即GC發(fā)生在什么時(shí)候？需要了解GC策略，與垃圾回收器實(shí)現(xiàn)有關(guān)；

3、如何回收？即需要了解垃圾回收算法，及算法的實(shí)現(xiàn)--垃圾回收器；

2.如何判斷對(duì)象可被回收

? 垃圾收集器對(duì)堆進(jìn)行回收前，首先要確定堆中的對(duì)象哪些還"存活"，哪些已經(jīng)"死去"。有兩種算法，分別是引用計(jì)數(shù)算法(Recference Counting)和可達(dá)性分析算法(Reachability Analysis)。

2.1 引用計(jì)數(shù)算法

2.1.1 算法思路

給對(duì)象添加一個(gè)引用計(jì)數(shù)器，每當(dāng)有一個(gè)地方引用它，計(jì)數(shù)器加1；當(dāng)引用失效，計(jì)數(shù)器值減1；任何時(shí)刻計(jì)數(shù)器值為0，則認(rèn)為對(duì)象是不再被使用的；

2.1.2 優(yōu)點(diǎn)

• 實(shí)現(xiàn)簡(jiǎn)單、垃圾便于辨識(shí)；
• 判定效率高，回收沒(méi)有延遲。

2.1.2 缺點(diǎn)

• 需要單獨(dú)的字段存儲(chǔ)計(jì)數(shù)器，額外的存儲(chǔ)空間開(kāi)銷(xiāo)
• 需要更新計(jì)數(shù)器，伴隨著加法和減法操作，帶來(lái)時(shí)間開(kāi)銷(xiāo)
• 無(wú)法處理循環(huán)引用的情況

循環(huán)引用的例子：

public class RefCountGC {
    //這個(gè)成員屬性唯一的作用就是占用一點(diǎn)內(nèi)存
    private byte[] bigSize = new byte[5 * 1024 * 1024];//5MB
    Object reference = null;
    public static void main(String[] args) {
        RefCountGC obj1 = new RefCountGC();
        RefCountGC obj2 = new RefCountGC();
        obj1.reference = obj2;
        obj2.reference = obj1;
        obj1 = null;
        obj2 = null;
        //顯式的執(zhí)行垃圾回收行為
        //這里發(fā)生GC，obj1和obj2能否被回收？ 能被回收，是因?yàn)镴VM采用的不是引用計(jì)數(shù)算法。所以obj1和obj2能被回收。這里反向證明了JVM沒(méi)有采用引用計(jì)數(shù)算法。
        System.gc();
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

2.2 可達(dá)性分析算法

2.2.1 算法思路

? 通過(guò)一系列的GC Roots的對(duì)象作為起始點(diǎn)，從這些根節(jié)點(diǎn)開(kāi)始向下搜索，搜索所走過(guò)的路徑稱(chēng)為引用鏈（Reference Chain），當(dāng)一個(gè)對(duì)象到GC Roots沒(méi)有任何引用鏈相連時(shí)，則證明此對(duì)象是不可用的。

2.2.2 GC Roots對(duì)象（兩棧兩方法）

• 虛擬機(jī)棧（棧幀中的本地變量表）中引用的對(duì)象
• 本地方法棧中 JNI（即一般說(shuō)的 Native 方法）引用的對(duì)象
• 方法區(qū)中類(lèi)靜態(tài)屬性引用的對(duì)象
• 方法區(qū)中常量引用的對(duì)象

2.2.3 優(yōu)點(diǎn)

更加精確和嚴(yán)謹(jǐn)，可以分析出循環(huán)數(shù)據(jù)結(jié)構(gòu)相互引用的情況；主流的編程語(yǔ)言Java c#的選擇。

2.2.4 缺點(diǎn)

• 消耗大量時(shí)間

從前面可達(dá)性分析知道，GC Roots主要在全局性的引用（常量或靜態(tài)屬性）和執(zhí)行上下文中（棧幀中的本地變量表）；
要在這些大量的數(shù)據(jù)中，逐個(gè)檢查引用，會(huì)消耗很多時(shí)間；

• GC停頓

可達(dá)性分析期間需要保證整個(gè)執(zhí)行系統(tǒng)的一致性，對(duì)象的引用關(guān)系不能發(fā)生變化；
導(dǎo)致GC進(jìn)行時(shí)必須停頓所有Java執(zhí)行線程（稱(chēng)為"Stop The World"）；
（幾乎不會(huì)發(fā)生停頓的CMS收集器中，枚舉根節(jié)點(diǎn)時(shí)也是必須要停頓的） Stop The World： 是JVM在后臺(tái)自動(dòng)發(fā)起和自動(dòng)完成的； 在用戶(hù)不可見(jiàn)的情況下，把用戶(hù)正常的工作線程全部停掉；

3.判斷對(duì)象生存還是死亡

3.1 兩次標(biāo)記過(guò)程

要真正宣告一個(gè)對(duì)象死亡，至少要經(jīng)歷兩次標(biāo)記過(guò)程。

1、第一次標(biāo)記

在可達(dá)性分析后發(fā)現(xiàn)到GC Roots沒(méi)有任何引用鏈相連時(shí)，被第一次標(biāo)記；并且進(jìn)行一次篩選：此對(duì)象是否必要執(zhí)行finalize()方法；

（A）、沒(méi)有必要執(zhí)行

沒(méi)有必要執(zhí)行的情況：（1）、對(duì)象沒(méi)有覆蓋finalize()方法；（2）、finalize()方法已經(jīng)被JVM調(diào)用過(guò)；這兩種情況就可以認(rèn)為對(duì)象已死，可以回收；

（B）、有必要執(zhí)行

對(duì)有必要執(zhí)行finalize()方法的對(duì)象，被放入F-Queue隊(duì)列中；稍后在JVM自動(dòng)建立、低優(yōu)先級(jí)的Finalizer線程（可能多個(gè)線程）中觸發(fā)這個(gè)方法；

2、第二次標(biāo)記

GC將對(duì)F-Queue隊(duì)列中的對(duì)象進(jìn)行第二次小規(guī)模標(biāo)記；finalize()方法是對(duì)象逃脫死亡的最后一次機(jī)會(huì)： （A）、如果對(duì)象在其finalize()方法中重新與引用鏈上任何一個(gè)對(duì)象建立關(guān)聯(lián)，第二次標(biāo)記時(shí)會(huì)將其移出"即將回收"的集合；（B）、如果對(duì)象沒(méi)有，也可以認(rèn)為對(duì)象已死，可以回收了；
一個(gè)對(duì)象的finalize()方法只會(huì)被系統(tǒng)自動(dòng)調(diào)用一次，經(jīng)過(guò)finalize()方法逃脫死亡的對(duì)象，第二次不會(huì)再調(diào)用；

3.2 finalize()方法

finalize()是Object類(lèi)的一個(gè)方法，是Java剛誕生時(shí)為了使C/C++程序員容易接受它所做出的一個(gè)妥協(xié)，但不要當(dāng)作類(lèi)似C/C++的析構(gòu)函數(shù)；因?yàn)樗鼒?zhí)行的時(shí)間不確定，甚至是否被執(zhí)行也不確定（Java程序的不正常退出），而且運(yùn)行代價(jià)高昂，無(wú)法保證各個(gè)對(duì)象的調(diào)用順序（甚至有不同線程中調(diào)用）；如果需要"釋放資源"，可以定義顯式的終止方法，并在"try-catch-finally"的finally{}塊中保證及時(shí)調(diào)用，如File相關(guān)類(lèi)的close()方法； 此外，finalize()方法主要有兩種用途：

1、充當(dāng)"安全網(wǎng)"

當(dāng)顯式的終止方法沒(méi)有調(diào)用時(shí)，在finalize()方法中發(fā)現(xiàn)后發(fā)出警告； 但要考慮是否值得付出這樣的代價(jià)； 如FileInputStream、FileOutputStream、Timer和Connection類(lèi)中都有這種應(yīng)用；

2、與對(duì)象的本地對(duì)等體有關(guān)

本地對(duì)等體：普通對(duì)象調(diào)用本地方法（JNI）委托的本地對(duì)象；
? 本地對(duì)等體不會(huì)被GC回收；?
? 如果本地對(duì)等體不擁有關(guān)鍵資源，finalize()方法里可以回收它（如C/C++中malloc()，需要調(diào)用free()）；?
? 如果有關(guān)鍵資源，必須顯式的終止方法；?
? 一般情況下，應(yīng)盡量避免使用它，甚至可以忘掉它。

4.HotSpot虛擬機(jī)中對(duì)象可達(dá)性分析的實(shí)現(xiàn)

4.1 枚舉根節(jié)點(diǎn)

枚舉根節(jié)點(diǎn)也就是查找GC Roots；

目前主流JVM都是準(zhǔn)確式GC，可以直接得知哪些地方存放著對(duì)象引用，所以執(zhí)行系統(tǒng)停頓下來(lái)后，并不需要全部、逐個(gè)檢查完全局性的和執(zhí)行上下文中的引用位置；

在HotSpot中，是使用一組稱(chēng)為OopMap的數(shù)據(jù)結(jié)構(gòu)來(lái)達(dá)到這個(gè)目的的；在類(lèi)加載時(shí)，計(jì)算對(duì)象內(nèi)什么偏移量上是什么類(lèi)型的數(shù)據(jù)；在JIT編譯時(shí)，也會(huì)記錄棧和寄存器中的哪些位置是引用；這樣GC掃描時(shí)就可以直接得知這些信息；

4.2 安全點(diǎn)

4.2.1 安全點(diǎn)是什么，為什么需要安全點(diǎn)

HotSpot在OopMap的幫助下可以快速且準(zhǔn)確的完成GC Roots枚舉，但是這有一個(gè)問(wèn)題：
運(yùn)行中，非常多的指令都會(huì)導(dǎo)致引用關(guān)系變化；如果為這些指令都生成對(duì)應(yīng)的OopMap，需要的空間成本太高；問(wèn)題解決：

只在特定的位置記錄OopMap引用關(guān)系，這些位置稱(chēng)為安全點(diǎn)（Safepoint）；即程序執(zhí)行時(shí)并非所有地方都能停頓下來(lái)開(kāi)始GC；

4.2.2 安全點(diǎn)的選定

不能太少，否則GC等待時(shí)間太長(zhǎng)；也不能太多，否則GC過(guò)于頻繁，增大運(yùn)行時(shí)負(fù)荷；所以，基本上是以程序"是否具有讓程序長(zhǎng)時(shí)間執(zhí)行的特征"為標(biāo)準(zhǔn)選定；"長(zhǎng)時(shí)間執(zhí)行"最明顯的特征就是指令序列復(fù)用，如：方法調(diào)用、循環(huán)跳轉(zhuǎn)、循環(huán)的末尾、異常跳轉(zhuǎn)等； 只有具有這些功能的指令才會(huì)產(chǎn)生Safepoint；

4.2.3 如何在安全點(diǎn)上停頓

對(duì)于Safepoint，如何在GC發(fā)生時(shí)讓所有線程（不包括JNI線程）運(yùn)行到其所在最近的Safepoint上再停頓下來(lái)？ 主要有兩種方案可選：

（A）、搶先式中斷（Preemptive Suspension）

不需要線程主動(dòng)配合，實(shí)現(xiàn)如下： （1）、在GC發(fā)生時(shí)，首先中斷所有線程； （2）、如果發(fā)現(xiàn)不在Safepoint上的線程，就恢復(fù)讓其運(yùn)行到Safepoint上； 現(xiàn)在幾乎沒(méi)有JVM實(shí)現(xiàn)采用這種方式；

（B）、主動(dòng)式中斷（Voluntary Suspension）

（1）、在GC發(fā)生時(shí)，不直接操作線程中斷，而是僅簡(jiǎn)單設(shè)置一個(gè)標(biāo)志； （2）、讓各線程執(zhí)行時(shí)主動(dòng)去輪詢(xún)這個(gè)標(biāo)志，發(fā)現(xiàn)中斷標(biāo)志為真時(shí)就自己中斷掛起
? 而輪詢(xún)標(biāo)志的地方和Safepoint是重合的；? 在JIT執(zhí)行方式下：test指令是HotSpot生成的輪詢(xún)指令；? 一條test匯編指令便完成Safepoint輪詢(xún)和觸發(fā)線程中斷；

4.3 安全區(qū)域

4.3.1 為什么需要安全區(qū)域

對(duì)于上面的Safepoint還有一個(gè)問(wèn)題： 程序不執(zhí)行時(shí)沒(méi)有CPU時(shí)間（Sleep或Blocked狀態(tài)），無(wú)法運(yùn)行到Safepoint上再中斷掛起；
? 這就需要安全區(qū)域來(lái)解決；

4.3.2 什么是安全區(qū)域（Safe Region）

指一段代碼片段中，引用關(guān)系不會(huì)發(fā)生變化； 在這個(gè)區(qū)域中的任意地方開(kāi)始GC都是安全的；

4.3.3 如何用安全區(qū)域解決問(wèn)題

安全區(qū)域解決問(wèn)題的思路：

（1）、線程執(zhí)行進(jìn)入Safe Region，首先標(biāo)識(shí)自己已經(jīng)進(jìn)入Safe Region；

（2）、線程被喚醒離開(kāi)Safe Region時(shí)，其需要檢查系統(tǒng)是否已經(jīng)完成根節(jié)點(diǎn)枚舉（或整個(gè)GC）；如果已經(jīng)完成，就繼續(xù)執(zhí)行；否則必須等待，直到收到可以安全離開(kāi)Safe Region的信號(hào)通知；

這樣就不會(huì)影響標(biāo)記結(jié)果；

5.垃圾回收算法

5.1 標(biāo)記清除

標(biāo)記-清除算法將垃圾回收分為兩個(gè)階段：標(biāo)記階段和清除階段。

標(biāo)記: Collector 從引用根節(jié)點(diǎn)開(kāi)始遍歷，標(biāo)記所有被引用的對(duì)象。一般是在對(duì)象的Header中記錄為可達(dá)對(duì)象。
清除: Collector對(duì)堆內(nèi)存從頭到尾進(jìn)行線性的遍歷，如果發(fā)現(xiàn)某個(gè)對(duì)象在其Header中沒(méi)有標(biāo)記為可達(dá)對(duì)象，則將其回收。這里所謂的清除并不是真的置空，而是把需要清除的對(duì)象地址保存在空閑的地址列表里。下次有新對(duì)象需要加載時(shí)，判斷垃圾的位置空間是否夠，如果夠，就存放。

適用場(chǎng)合：

• 存活對(duì)象較多的情況下比較高效
• 適用于年老代（即舊生代）

缺點(diǎn)：

• 容易產(chǎn)生內(nèi)存碎片，再來(lái)一個(gè)比較大的對(duì)象時(shí)（典型情況：該對(duì)象的大小大于空閑表中的每一塊兒大小但是小于其中兩塊兒的和），會(huì)提前觸發(fā)垃圾回收而且需要維護(hù)一個(gè)空閑列表
• 效率不算高（第一次：標(biāo)記存活對(duì)象；第二次：清除沒(méi)有標(biāo)記的對(duì)象）
• 在進(jìn)行GC的時(shí)候，需要停止整個(gè)應(yīng)用程序，導(dǎo)致用戶(hù)體驗(yàn)差

5.2 復(fù)制算法

將活著的內(nèi)存空間分為兩塊，每次只使用其中一塊，在垃圾回收時(shí)將正在使用的內(nèi)存中的存活對(duì)象復(fù)制到未被使用的內(nèi)存塊中，之后清除正在使用的內(nèi)存塊中的所有對(duì)象，交換兩個(gè)內(nèi)存的角色，最后完成垃圾收。

?在新生代，對(duì)常規(guī)應(yīng)用的垃圾回收，一 次通?？梢曰厥?0%-99%的內(nèi)存空間。回收性?xún)r(jià)比很高。所以現(xiàn)在的商業(yè)虛擬機(jī)都是用這種收集算法回收新生代。

適用場(chǎng)合：

• 存活對(duì)象較少的情況下比較高效
• 掃描了整個(gè)空間一次（標(biāo)記存活對(duì)象并復(fù)制移動(dòng)）
• 適用于年輕代（即新生代）：基本上98%的對(duì)象是”朝生夕死”的，存活下來(lái)的會(huì)很少

優(yōu)點(diǎn)：

• 沒(méi)有標(biāo)記和清除過(guò)程，實(shí)現(xiàn)簡(jiǎn)單，運(yùn)行高效
• 復(fù)制過(guò)去以后保證空間的連續(xù)性，不會(huì)出現(xiàn)“碎片”問(wèn)題。

缺點(diǎn)：

• 需要兩倍的內(nèi)存空間
• 對(duì)于G1這種分拆成為大量region的GC，復(fù)制而不是移動(dòng)，意味著GC需要維護(hù)region之間對(duì)象引用關(guān)系，不管是內(nèi)存占用或者時(shí)間開(kāi)銷(xiāo)也不小

5.3 標(biāo)記整理

復(fù)制算法的高效性是建立在存活對(duì)象少、垃圾對(duì)象多的前提下的。

這種情況在新生代經(jīng)常發(fā)生，但是在老年代更常見(jiàn)的情況是大部分對(duì)象都是存活對(duì)象。如果依然使用復(fù)制算法，由于存活的對(duì)象較多，復(fù)制的成本也將很高。

執(zhí)行過(guò)程：

標(biāo)記-壓縮算法的最終效果等同于標(biāo)記-清除算法執(zhí)行完成后，再進(jìn)行一次內(nèi)存碎片整理，因此，也可以把它稱(chēng)為標(biāo)記-清除-壓縮(Mark- Sweep-Compact)算法。
二者的本質(zhì)差異在于標(biāo)記-清除算法是一種非移動(dòng)式的回收算法，標(biāo)記-壓縮是移動(dòng)式的。是否移動(dòng)回收后的存活對(duì)象是一-項(xiàng)優(yōu)缺點(diǎn)并存的風(fēng)險(xiǎn)決策。
可以看到，標(biāo)記的存活對(duì)象將會(huì)被整理，按照內(nèi)存地址依次排列，而未被標(biāo)記的內(nèi)存會(huì)被清理掉。如此一-來(lái)，當(dāng)我們需要給新對(duì)象分配內(nèi)存時(shí)，JVM只需要持有一個(gè)內(nèi)存的起始地址即可，這比維護(hù)一個(gè)空閑列表顯然少了許多開(kāi)銷(xiāo)。

優(yōu)點(diǎn):

• 消除了標(biāo)記-清除算法當(dāng)中，內(nèi)存區(qū)域分散的缺點(diǎn)，我們需要給新對(duì)象分配內(nèi)存時(shí)，JVM只 需要持有一個(gè)內(nèi)存的起始地址即可。消除了復(fù)制算法當(dāng)中，內(nèi)存減半的高額代價(jià)。

缺點(diǎn):

• 從效率上來(lái)說(shuō)，標(biāo)記-整理算法要低于復(fù)制算法。移動(dòng)對(duì)象的同時(shí)，如果對(duì)象被其他對(duì)象引用，則還需要調(diào)整引用的地址。移動(dòng)過(guò)程中，需要全程暫停用戶(hù)應(yīng)用程序。即: STW

對(duì)比三種算法

5.4 分代收集算法

把堆內(nèi)存分為新生代和老年代，新生代又分為 Eden 區(qū)、From Survivor 和 To Survivor。一般新生代中的對(duì)象基本上都是朝生夕滅的，每次只有少量對(duì)象存活，因此采用復(fù)制算法，只需要復(fù)制那些少量存活的對(duì)象就可以完成垃圾收集；老年代中的對(duì)象存活率較高，就采用標(biāo)記-清除和標(biāo)記-整理算法來(lái)進(jìn)行回收。

在這些區(qū)域的垃圾回收大概有如下幾種情況：

在這些區(qū)域的垃圾回收大概有如下幾種情況：

大多數(shù)情況下，新的對(duì)象都分配在Eden區(qū)，當(dāng) Eden 區(qū)沒(méi)有空間進(jìn)行分配時(shí)，將進(jìn)行一次 Minor GC，清理 Eden 區(qū)中的無(wú)用對(duì)象。清理后，Eden 和 From Survivor 中的存活對(duì)象如果小于To Survivor 的可用空間則進(jìn)入To Survivor，否則直接進(jìn)入老年代）；Eden 和 From Survivor 中還存活且能夠進(jìn)入 To Survivor 的對(duì)象年齡增加 1 歲（虛擬機(jī)為每個(gè)對(duì)象定義了一個(gè)年齡計(jì)數(shù)器，每執(zhí)行一次 Minor GC 年齡加 1），當(dāng)存活對(duì)象的年齡到達(dá)一定程度（默認(rèn) 15 歲）后進(jìn)入老年代，可以通過(guò) -XX:MaxTenuringThreshold 來(lái)設(shè)置年齡的值。

當(dāng)進(jìn)行了 Minor GC 后，Eden 還不足以為新對(duì)象分配空間（那這個(gè)新對(duì)象肯定很大），新對(duì)象直接進(jìn)入老年代。

占 To Survivor 空間一半以上且年齡相等的對(duì)象，大于等于該年齡的對(duì)象直接進(jìn)入老年代，比如 Survivor 空間是 10M，有幾個(gè)年齡為 4 的對(duì)象占用總空間已經(jīng)超過(guò) 5M，則年齡大于等于 4 的對(duì)象都直接進(jìn)入老年代，不需要等到 MaxTenuringThreshold 指定的歲數(shù)。

在進(jìn)行 Minor GC 之前，會(huì)判斷老年代最大連續(xù)可用空間是否大于新生代所有對(duì)象總空間，如果大于，說(shuō)明 Minor GC 是安全的，否則會(huì)判斷是否允許擔(dān)保失敗，如果允許，判斷老年代最大連續(xù)可用空間是否大于歷次晉升到老年代的對(duì)象的平均大小，如果大于，則執(zhí)行 Minor GC，否則執(zhí)行 Full GC。

當(dāng)在 java 代碼里直接調(diào)用 System.gc() 時(shí)，會(huì)建議 JVM 進(jìn)行 Full GC，但一般情況下都會(huì)觸發(fā) Full GC，一般不建議使用，盡量讓虛擬機(jī)自己管理 GC 的策略。

永久代（方法區(qū)）中用于存放類(lèi)信息，jdk1.6 及之前的版本永久代中還存儲(chǔ)常量、靜態(tài)變量等，當(dāng)永久代的空間不足時(shí)，也會(huì)觸發(fā) Full GC，如果經(jīng)過(guò) Full GC 還無(wú)法滿(mǎn)足永久代存放新數(shù)據(jù)的需求，就會(huì)拋出永久代的內(nèi)存溢出異常。

大對(duì)象（需要大量連續(xù)內(nèi)存的對(duì)象）例如很長(zhǎng)的數(shù)組，會(huì)直接進(jìn)入老年代，如果老年代沒(méi)有足夠的連續(xù)大空間來(lái)存放，則會(huì)進(jìn)行 Full GC。

6.參考

1.JVM：引用計(jì)數(shù)算法和可達(dá)性分析算法(https://www.zhifou.net/blogdetail/183)

2.4種JVM垃圾回收算法詳解（https://mikechen.cc/7102.html）

3.深入理解Java虛擬機(jī)（四）之垃圾回收算法(https://www.codenong.com/cs106639755/)

到此這篇關(guān)于最新JVM垃圾回收算法詳解的文章就介紹到這了,更多相關(guān)JVM垃圾回收算法內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論