詳解JVM 的垃圾回收算法和垃圾回收器

作者 | 崔皓

開篇

我們知道JVM的垃圾回收機(jī)制實(shí)際上是對(duì)JVM內(nèi)存的操作，回收的目的是為了避免內(nèi)存溢出和內(nèi)存泄漏的問題。而JVM內(nèi)存由方法區(qū)、堆、虛擬機(jī)棧、本地方法棧以及程序計(jì)數(shù)器5塊區(qū)域組成，虛擬機(jī)棧、本地方法棧、程序計(jì)數(shù)器是隨著Java線程建立而建立，當(dāng)Java 線程完成之后這三個(gè)部分的內(nèi)存就會(huì)被釋放掉。

而方法區(qū)和堆屬于共有線程，是隨著JVM啟動(dòng)而建立的，而且這兩個(gè)區(qū)域與另外三個(gè)區(qū)域也有所不同，一個(gè)接口中有多少個(gè)實(shí)現(xiàn)類（方法區(qū)）以及每次程序運(yùn)行需要?jiǎng)?chuàng)建多少對(duì)象（堆）是動(dòng)態(tài)的，也就是說在程序運(yùn)行時(shí)才能知道。

為了讓這部分動(dòng)態(tài)的內(nèi)存分配能夠進(jìn)行合理的回收，就需要垃圾回收算法和垃圾回收器來幫忙了。下面讓我們進(jìn)入今天的主題。

如何判斷對(duì)象“存活”？

JVM 垃圾回收機(jī)制是對(duì)堆中沒有使用的對(duì)象進(jìn)行回收，那么判斷對(duì)象是否“存活”就至關(guān)重要。在判斷對(duì)象是否“存活”的方法中，我們會(huì)介紹引用計(jì)數(shù)算法和可達(dá)性分析法。

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

Java堆中針對(duì)每個(gè)對(duì)象都設(shè)置一個(gè)引用計(jì)數(shù)器。當(dāng)一個(gè)對(duì)象被創(chuàng)建并初始化賦值后，該變量計(jì)數(shù)設(shè)置為1。每當(dāng)有一個(gè)地方引用它時(shí)，計(jì)數(shù)器值就加1。當(dāng)引用失效時(shí)，即一個(gè)對(duì)象的某個(gè)引用超過了生命周期（出作用域后）或者被設(shè)置為一個(gè)新值時(shí)，計(jì)數(shù)器值就減1。任何引用計(jì)數(shù)為0的對(duì)象可以被當(dāng)作垃圾回收。當(dāng)一個(gè)對(duì)象被垃圾回收時(shí)，它引用的任何對(duì)象計(jì)數(shù)減1。

這種方法的優(yōu)點(diǎn)很明顯，引用計(jì)數(shù)回收器執(zhí)行簡(jiǎn)單，判定效率高，對(duì)程序不被長(zhǎng)時(shí)間打斷的實(shí)時(shí)環(huán)境比較有利。不過缺點(diǎn)也很明顯，對(duì)于對(duì)象循環(huán)引用的場(chǎng)景難以判斷，同時(shí)引用計(jì)數(shù)器增加了程序執(zhí)行的開銷。Java語(yǔ)言并沒有選擇這種算法進(jìn)行垃圾回收。

可達(dá)性分析法

可達(dá)性分析法也叫根搜索算法，通過稱為 GC Roots 的對(duì)象作為起點(diǎn)，從上往下進(jìn)行搜索。搜索所走過的路徑稱為引用鏈 （Reference Chain）， 當(dāng)發(fā)現(xiàn)某個(gè)對(duì)象與 GC Roots之間沒有任何引用鏈相連時(shí), 即認(rèn)為該對(duì)象不可達(dá)，該對(duì)象也就成了垃圾回收的目標(biāo)。

如圖1 所示，從GC Roots 開始沒有引用鏈和Obejct5、Object6 和Object7 相連，因此這三個(gè)對(duì)象對(duì)于GC Roots 而言就是不可達(dá)的，會(huì)被垃圾回收，即便他們互相都有引用。

圖1 可達(dá)性分析法

在Java中，可作為GC Roots的對(duì)象包括如下四種：

虛擬機(jī)棧（棧幀中的本地變量表）中引用的對(duì)象

本地方法棧 中 JNI （Native方法）引用的變量

方法區(qū) 中類靜態(tài)屬性引用的變量

方法區(qū) 中常量引用的變量

前面談到的可達(dá)實(shí)際上是在判斷對(duì)象是否被引用，如果沒有被引用，垃圾回收器會(huì)將其進(jìn)行回收。不過我們希望存在這樣一些對(duì)象，當(dāng)內(nèi)存空間足夠的情況下盡量將其保留在內(nèi)存中，當(dāng)內(nèi)存不夠的情況下，再回收這些對(duì)象。下面看看如何對(duì)如下對(duì)象進(jìn)行處理：

強(qiáng)引用(Strong Reference)：例如，Object obj = new Object()這類引用，只要強(qiáng)引用存在，垃圾回收器永遠(yuǎn)不會(huì)回收掉被引用的對(duì)象。

軟引用(Soft Reference)：在系統(tǒng)將要出現(xiàn)內(nèi)存溢出之前，會(huì)將軟引用對(duì)象列進(jìn)回收范圍之中進(jìn)行二次回收。如果這次回收還沒有足夠的內(nèi)存，才會(huì)拋出內(nèi)存溢出異常。

弱引用(Weak Reference)：被弱引用關(guān)聯(lián)的對(duì)象只能生存到下一次垃圾回收發(fā)生之前，無(wú)論當(dāng)前內(nèi)存是否足夠，用軟引用相關(guān)聯(lián)的對(duì)象都會(huì)被回收掉。

虛引用(Phantom Reference)：虛引用也稱為幽靈引用或幻影引用，是最弱的一種引用關(guān)系，為一個(gè)對(duì)象設(shè)置虛引用的唯一目的是：能在這個(gè)對(duì)象在垃圾回收器回收的時(shí)候收到一個(gè)系統(tǒng)通知。

垃圾回收算法

上面講解了如何發(fā)現(xiàn)“存活”對(duì)象，JVM中會(huì)使用可達(dá)性分析法，說白了就是看GC Roots在引用鏈上是否有對(duì)應(yīng)的對(duì)象被引用到了。接下來就在這個(gè)背景下看看有哪些垃圾回收的算法，這里我們列舉出常見的幾種：

標(biāo)記清除算法

該算法分為標(biāo)記和清除兩個(gè)階段，首先通過可達(dá)性分析法找到要回收的對(duì)象，也就是沒有被引用的對(duì)象，對(duì)其進(jìn)行標(biāo)記，然后再對(duì)該對(duì)象進(jìn)行清除也就是回收了。

如圖2 所示，該算法會(huì)對(duì)內(nèi)存空間進(jìn)行掃描，發(fā)現(xiàn)GC Roots 對(duì)Object1 和Object2 進(jìn)行引用，但是對(duì)Object2 沒有引用。首先標(biāo)記Object2 沒有被引用。

圖2

如圖3 所示，算法再次對(duì)內(nèi)存進(jìn)行掃描，清除Object2 對(duì)象占用的空間，將其設(shè)置為空閑空間。

圖3 標(biāo)記清除算法

該算法的優(yōu)點(diǎn)就是簡(jiǎn)單粗暴，沒有引用的對(duì)象會(huì)被清除掉，但是缺點(diǎn)是效率問題。標(biāo)記和清除操作會(huì)掃描整個(gè)空間兩次（第一次：標(biāo)記存活對(duì)象；第二次：清除沒有標(biāo)記的對(duì)象）才能完成清理工作。同時(shí)清理過程容易產(chǎn)生內(nèi)存碎片，這些空閑的空間無(wú)法容納大對(duì)象，如果此時(shí)有一個(gè)比較大的對(duì)象進(jìn)入內(nèi)存，由于該內(nèi)存中沒有連續(xù)的容納大對(duì)象的空間，就會(huì)提前觸發(fā)垃圾回收。

復(fù)制算法

為了解決標(biāo)記清除法帶來的問題，復(fù)制算法將內(nèi)存劃分為大小相等的兩塊，每次使用其中的一塊，當(dāng)這塊的內(nèi)存使用完畢以后，再將對(duì)象復(fù)制到另外一塊上面，然后對(duì)已經(jīng)使用過的內(nèi)存空間進(jìn)行清理。這樣每次對(duì)內(nèi)存的一半?yún)^(qū)域進(jìn)行回收，不用考慮內(nèi)存碎片的問題。

如圖4 所示，上面的區(qū)域是垃圾回收之前的內(nèi)存空間，我們用黑色的虛線將內(nèi)存分為兩個(gè)部分。左邊的部分是正在使用的空間，右邊是預(yù)留空間。左邊區(qū)域中紅色的部分是不可回收的內(nèi)存，也就是說這里面有被GC Roots 引用的對(duì)象，另外灰色的部分是可回收的區(qū)域，也就是沒有被GC Roots 引用的對(duì)象，白色區(qū)域是未分配的。

如果通過復(fù)制算法進(jìn)行垃圾回收，順著綠色的箭頭向下，在回收后的內(nèi)存區(qū)域可以看到，將左側(cè)紅色的內(nèi)存對(duì)象移動(dòng)到了右側(cè)預(yù)留的區(qū)域，并且按照順序排放。然后對(duì)左側(cè)運(yùn)行的內(nèi)存區(qū)域進(jìn)行清理，成為預(yù)留區(qū)域等待第二次垃圾回收的執(zhí)行。

圖4 復(fù)制算法

復(fù)制算法的優(yōu)點(diǎn)是簡(jiǎn)單高效，不會(huì)出現(xiàn)內(nèi)存碎片。缺點(diǎn)也明顯，內(nèi)存利用率低，只有一半的內(nèi)存被利用。特別是存活對(duì)象較多時(shí)效率明顯降低，因?yàn)樾枰苿?dòng)每個(gè)不可回收數(shù)據(jù)的內(nèi)存實(shí)際位置。

標(biāo)記整理算法

該算法和標(biāo)記清除算法相似，但是后續(xù)步驟并不是直接對(duì)可回收對(duì)象進(jìn)行清理，而是讓所有存活對(duì)象都移動(dòng)到內(nèi)存的前端，然后再清除掉其他可回收的對(duì)象所占用的內(nèi)存空間。

如圖5 所示，回收前的內(nèi)存中紅色為不可回收的內(nèi)存空間，灰色是可回收空間，白色是未分配空間。執(zhí)行標(biāo)記整理算法的垃圾回收之后，將不可回收的內(nèi)存空間整理到內(nèi)存的前端，同時(shí)清除掉可回收的內(nèi)存空間，此時(shí)不可回收空間之后存放的都是白色的未分配空間，供由新對(duì)象存放。

圖5 標(biāo)記整理算法

標(biāo)記整理算法優(yōu)點(diǎn)是解決了標(biāo)記清理算法存在的內(nèi)存碎片問題。缺點(diǎn)也是非常明顯，需要進(jìn)行局部對(duì)象移動(dòng)，一定程度上降低了效率。

分代收集算法

分代收集算法，顧名思義是根據(jù)對(duì)象的存活周期將內(nèi)存劃分為幾塊，然后定義回收規(guī)則。如圖6所示，從左到右分別是年輕代（Young Generation）、老年代（Old Generation） 和 永久代（Permanent Generation），另外年輕代又分為了Eden Space（伊甸空間） 、Survivor Space（幸存者空間）。分代收集的算法在當(dāng)前商業(yè)虛擬機(jī)算法中被廣泛采用。

圖6 分代收集法

上面對(duì)分代收集法做了字面的解釋，現(xiàn)將該算法的執(zhí)行過程描述如下：

1）新產(chǎn)生的對(duì)象優(yōu)先分配在Eden區(qū)（除非配置了-XX:PretenureSizeThreshold，大于該值的對(duì)象會(huì)直接進(jìn)入老年代）。有這樣一種情況，當(dāng)對(duì)象剛剛在新生代創(chuàng)建就被回收了，對(duì)象從這個(gè)區(qū)域消失的過程我們稱之為 minor GC。

2）當(dāng)Eden區(qū)滿了或放不下了，這時(shí)候其中存活的對(duì)象會(huì)復(fù)制到from區(qū)。如果此時(shí)存活下來的對(duì)象在from 區(qū)都放不下，就會(huì)放到老年代，之后Eden 區(qū)的內(nèi)存會(huì)全部回收掉。

3）之后產(chǎn)生的對(duì)象繼續(xù)分配在Eden區(qū)，當(dāng)Eden區(qū)又滿了或放不下了，這時(shí)候?qū)?huì)把Eden區(qū)和from區(qū)存活下來的對(duì)象復(fù)制到to區(qū)，此時(shí)如果存活下來的對(duì)象to區(qū)也放不下，會(huì)將其移動(dòng)到年老代，同時(shí)會(huì)回收掉Eden區(qū)和from區(qū)的內(nèi)存。

4）如果按照如上操作將對(duì)象在幾個(gè)區(qū)域中移動(dòng)，會(huì)出現(xiàn)對(duì)象被多次復(fù)制的情況，對(duì)象被復(fù)制一次，對(duì)象的年齡就會(huì)+1。默認(rèn)情況下，當(dāng)對(duì)象被復(fù)制了15次（通過：-XX:MaxTenuringThreshold來配置），該對(duì)象就會(huì)進(jìn)入老年代了。

5）當(dāng)老年代滿了的情況下，就會(huì)發(fā)生一次Full GC。

備注：Minor GC指發(fā)生在新生代的垃圾收集動(dòng)作，因?yàn)镴ava對(duì)象大多都具備朝生夕滅的特性，所以Minor GC非常頻繁，一般回收速度也比較快。Full GC指發(fā)生在老年代的GC，出現(xiàn)了Full GC，經(jīng)常會(huì)伴隨至少一次的Full GC，F(xiàn)ull GC的速度一般會(huì)比Minor GC慢10倍以上。

垃圾回收器

如果垃圾回收算法是內(nèi)存回收的方法論的話，那么垃圾回收器就是內(nèi)存回收的具體實(shí)現(xiàn)了。下面會(huì)針對(duì)JDK1.7 Update 14 之后的HotSpot虛擬機(jī)給大家做介紹。

如圖7所示，這里將內(nèi)存分為新生代和老年代，將7種不同垃圾回收器分布于其間，垃圾回收器之間存在連線，說明它們可以搭配使用。

虛擬機(jī)所處的區(qū)域，則表示它是屬于新生代收集器還是老年代收集器。Hotspot實(shí)現(xiàn)了如此多的收集器，正是因?yàn)槟壳安o(wú)完美的收集器出現(xiàn)，只是選擇對(duì)具體應(yīng)用最適合的收集器。

圖7垃圾回收器的分類

下面就來介紹這幾個(gè)垃圾回收器：

Serial回收器

Serial（串行）回收器采用復(fù)制算法的新生代收集器，它是一個(gè)單線程回收器，針對(duì)一個(gè)CPU或一條收集線程去完成垃圾收集工作，它在進(jìn)行垃圾收集時(shí)，必須暫停其他所有的工作線程，直至Serial收集器收集結(jié)束為止，這個(gè)做法也稱為 “Stop The World”。

如圖8 所示，左邊多個(gè)應(yīng)用程序線程在執(zhí)行， 當(dāng)Serial 回收器的GC線程（虛線部分）執(zhí)行的時(shí)候，應(yīng)用程序線程（左邊多個(gè)實(shí)線）都會(huì)暫停，只有在回收器線程執(zhí)行完畢以后，應(yīng)用程序線程（右邊多個(gè)實(shí)線）才會(huì)繼續(xù)執(zhí)行。

圖 8 串行垃圾回收器

該回收器的問題就是在進(jìn)行垃圾回收時(shí)其他工作線程必須停頓，不過它在HotSpot虛擬機(jī)運(yùn)行的Client模式下可以為新生代回收器服務(wù)。它的簡(jiǎn)單而高效對(duì)于限定單個(gè)CPU的環(huán)境來說，Serial回收器沒有線程交互的開銷。在用戶的桌面應(yīng)用場(chǎng)景中，分配給虛擬機(jī)管理的內(nèi)存不大，停頓時(shí)間可以控制在幾十毫秒以內(nèi)，還是可以接收。它對(duì)于運(yùn)行在Client模式下的虛擬機(jī)來說是一個(gè)很好的選擇。

ParNew 回收器

ParNew回收器是Serial回收器的多線程版本，它也是一個(gè)新生代回收器。除了使用多線程進(jìn)行垃圾收集外，其余行為包括Serial收集器可用的所有控制參數(shù)、收集算法（復(fù)制算法）、Stop The World、對(duì)象分配規(guī)則、回收策略等。

如圖9 所示，與Serial 不同的是ParNew 使用多個(gè)線程（中間多條虛線）的方式進(jìn)行垃圾回收。

圖9 ParNew 并行回收器

ParNew 回收器在多CPU環(huán)境下垃圾回收的效率會(huì)有明顯提高。它默認(rèn)開啟的收集線程數(shù)與CPU的數(shù)量相同，在CPU非常多的情況下可使用-XX:ParallerGCThreads參數(shù)設(shè)置。反過來，如果針對(duì)單個(gè)CPU的環(huán)境 ParNew 和Serial 回收器的效果就難分伯仲了。

Serial Old回收器

Serial Old 是 Serial回收器的老年代版本，是單線程收集器，使用標(biāo)記整理（Mark-Compact）算法。它可以給Client模式下的虛擬機(jī)使用。如果在Server模式下，它還有兩大用途：在JDK1.5 以及之前版本（Parallel Old誕生以前）中與Parallel Scavenge收集器搭配使用。作為CMS收集器的后備預(yù)案，在并發(fā)收集發(fā)生Concurrent Mode Failure時(shí)使用。

Parallel Old回收器

Parallel Old回收器是Parallel Scavenge的老年代版本，使用多線程的標(biāo)記整理算法。在JDK 1.6中才開始提供，如果新生代選擇了Parallel Scavenge收集器，老年代除了Serial Old以外別無(wú)選擇。Parallel Old回收器的工作流程與Parallel Scavenge相同。

Parallel Scavenge 回收器

Parallel Scavenge回收器是并行的多線程新生代回收器，它使用復(fù)制算法。Parallel Scavenge回收器的目標(biāo)是達(dá)到一個(gè)可控制的吞吐量（Throughput）。

這里稍微說明一下， 吞吐量就是CPU運(yùn)行用戶代碼時(shí)間與CPU總消耗時(shí)間的比值，表現(xiàn)成工時(shí)是：吞吐量 = 用戶代碼運(yùn)行時(shí)間 /（用戶代碼運(yùn)行時(shí)間 + 垃圾回收時(shí)間）。用戶代碼運(yùn)行時(shí)間95 分鐘，垃圾回收時(shí)間為5分鐘，那吞吐量就是95/（95+5）=95%。

高吞吐量說明垃圾回收器高效率地利用CPU時(shí)間，盡快完成程序的運(yùn)算任務(wù)。從而讓垃圾回收造成的停頓時(shí)間變短，適合與用戶交互的程序提升用戶體驗(yàn)。

Parallel Scavenge會(huì)提供精確控制吞吐量的參數(shù)，此外還通過對(duì)參數(shù)-XX:+UseAdaptiveSizePolicy 設(shè)置來自動(dòng)調(diào)節(jié)新生代的大?。?Xmn）、Eden和Survivor區(qū)的比例（-XX:SurvivorRatio）、晉升老年代對(duì)象年齡（-XX:PretenureSizeThreshold）等信息。

此外Parallel Scavenge 回收器還有一個(gè)特點(diǎn)就是，會(huì)根據(jù)當(dāng)前系統(tǒng)的運(yùn)行情況收集性能監(jiān)控信息，動(dòng)態(tài)調(diào)整這些參數(shù)以提供最合適的停頓時(shí)間或者最大的吞吐量，我們稱之為GC自適應(yīng)的調(diào)節(jié)策略（GC Ergonomics）。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是以獲取最短回收停頓時(shí)間為目標(biāo)的回收器，它適用于重視響應(yīng)速度的應(yīng)用場(chǎng)景，它是基于標(biāo)記清除算法而實(shí)現(xiàn)的。

如圖10 所示，從左往右CMS工作流程分為以下4個(gè)步驟：

初始標(biāo)記（CMS initial mark）：標(biāo)記GC Roots直接關(guān)聯(lián)到的對(duì)象，需要執(zhí)行“Stop The World”，也就是讓工作線程暫停。

并發(fā)標(biāo)記（CMS concurrent mark）：從GC Roots 查找所有可達(dá)的對(duì)象，這個(gè)過程耗時(shí)比較長(zhǎng)，此時(shí)用戶線程依舊在運(yùn)行。

重新標(biāo)記（CMS remark）：修正并發(fā)標(biāo)記期間，用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記的對(duì)象，并且調(diào)整標(biāo)記記錄，此階段也需要“Stop The World”，因?yàn)椴粫和９ぷ骶€程的話還可能有標(biāo)記不準(zhǔn)確的情況發(fā)生。

并發(fā)清除（CMS concurrent sweep）：對(duì)于標(biāo)記不可用的對(duì)象進(jìn)行并發(fā)清除操作，這個(gè)過程耗時(shí)會(huì)比較長(zhǎng)，此時(shí)工作線程依舊可以運(yùn)行。

所以，從總體上來說，CMS收集器的內(nèi)存回收過程是與用戶線程一起并發(fā)執(zhí)行的。通過下圖可以比較清楚地看到CMS收集器的運(yùn)作步驟中并發(fā)和需要停頓的時(shí)間：

圖10 CMS 垃圾回收器

CMS的優(yōu)點(diǎn)明顯，并發(fā)收集、低停頓。不過他對(duì)CPU資源非常敏感，在并發(fā)階段雖然不會(huì)導(dǎo)致用戶線程暫停，但會(huì)因?yàn)檎加昧艘徊糠志€程（或者說CPU資源）而導(dǎo)致應(yīng)用程序變慢，總吞吐量會(huì)降低。

CMS默認(rèn)啟動(dòng)的回收線程數(shù)是（CPU數(shù)量+3）/4，也就是當(dāng)CPU在4個(gè)以上時(shí)，并發(fā)回收時(shí)垃圾收集線程不少于25%的CPU資源，并且隨著CPU數(shù)量的增加而下降。但是當(dāng)CPU不足4個(gè)時(shí)（比如2個(gè)），CMS對(duì)用戶程序的影響就可能變得很大，如果本來CPU負(fù)載就比較大，還要分出一半的運(yùn)算能力去執(zhí)行收集器線程，就可能導(dǎo)致用戶程序的執(zhí)行速度忽然降低了50%。

無(wú)法處理浮動(dòng)垃圾（Floating Garbage） 可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。在垃圾回收階段，用戶線程還在運(yùn)行，還需要預(yù)留有足夠的內(nèi)存空間給用戶線程使用，因此CMS需要預(yù)留一部分空間提供并發(fā)收集時(shí)的程序運(yùn)作使用。標(biāo)記清除算法本身也會(huì)導(dǎo)致產(chǎn)生大量的空間碎片。

G1回收器

G1（Garbage-First）回收器是面向服務(wù)端應(yīng)用的垃圾回收器，它具備如下特點(diǎn)：

充分利用多CPU縮短“Stop The World”停頓時(shí)間，可以通過并發(fā)的方式讓Java程序繼續(xù)執(zhí)行。

不需要其他回收器配合就能獨(dú)立管理整個(gè)GC堆，采用不同方式去處理新創(chuàng)建的對(duì)象和已存活一段時(shí)間、對(duì)于經(jīng)歷過多次GC的舊對(duì)象來說會(huì)有更好的回收效果。

G1基本上是基于標(biāo)記整理算法實(shí)現(xiàn)的，在局部（兩個(gè)Region之間）是基于復(fù)制算法實(shí)現(xiàn)的。這意味著G1運(yùn)行期間不會(huì)產(chǎn)生內(nèi)存空間碎片，收集后能提供規(guī)整的可用內(nèi)存。此特性有利于程序長(zhǎng)時(shí)間運(yùn)行，分配大對(duì)象時(shí)不會(huì)因?yàn)闊o(wú)法找到連續(xù)內(nèi)存空間而提前觸發(fā)下一次GC。

可預(yù)測(cè)的停頓時(shí)間模型，能讓使用者明確指定在一個(gè)長(zhǎng)度為M毫秒的時(shí)間片段內(nèi)，消耗在GC上的時(shí)間不得超過N毫秒。

與其他垃圾回收器不同的是，G1回收的范圍橫跨整個(gè)堆內(nèi)存。

如圖11所示，G1將堆劃分為多個(gè)大小相等的區(qū)域（Region），雖然還保留新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，而是Region的集合。

圖11 G1 將堆進(jìn)行分Region

前面提到G1回收器可以預(yù)測(cè)的停頓時(shí)間，是因?yàn)樗苊庠谡麄€(gè)Java堆中進(jìn)行全區(qū)域的垃圾回收。G1會(huì)跟蹤各個(gè)Region的垃圾堆積的價(jià)值大?。ɑ厥盏目臻g大小以及回收所需時(shí)間的經(jīng)驗(yàn)值），在后臺(tái)維護(hù)一個(gè)優(yōu)先列表，每次根據(jù)允許的回收時(shí)間，優(yōu)先回收價(jià)值最大的Region。

雖然G1把Java堆分為多個(gè)Region，在某個(gè)Region中的對(duì)象可以與位于其他Region中的任意對(duì)象發(fā)生引用關(guān)系。在做可達(dá)性分析時(shí)仍然需要掃描整個(gè)堆，顯然這樣做效率是不高的。為了避免全堆掃描， G1為每個(gè)Region維護(hù)了一個(gè)記憶集（Remembered Set）。當(dāng)發(fā)現(xiàn)程序在對(duì)引用（Reference）類型的數(shù)據(jù)進(jìn)行寫操作時(shí)，會(huì)產(chǎn)生一個(gè)Write Barrier暫時(shí)中斷寫操作。然后檢查引用（Reference）對(duì)象是否處于不同的Region之中，如果是便通過CardTable把相關(guān)引用信息記錄到被引用對(duì)象所屬的Region的記憶集（Remembered Set）之中。當(dāng)進(jìn)行內(nèi)存回收時(shí)，在GC根節(jié)點(diǎn)的枚舉范圍中加入Remembered Set即可保證不對(duì)全堆掃描也不會(huì)有遺漏。說白了就是通過Remembered Set 記錄跨Region引用的對(duì)象，其目的是避免全堆掃描。

如圖12所示，Region2 中的兩個(gè)對(duì)象分配被Region1 和Region3 中的對(duì)象引用，因此在Region2中的記憶集（Remembered set）就會(huì)記錄這兩個(gè)引用的信息，在垃圾回收的時(shí)候只需要收集記憶集的信息就知道對(duì)象在每個(gè)Region 的引用關(guān)系了，并不需要掃描所有堆的Region。

圖12 跨Region的對(duì)象引用

說了G1 的特點(diǎn)和機(jī)制，下面通過圖13 來看看它的執(zhí)行過程：

初始標(biāo)記（Initial Marking）：標(biāo)記GC Roots 能直接引用的對(duì)象，讓下一階段用戶程序并發(fā)運(yùn)行時(shí)，能在正確的Region中創(chuàng)建對(duì)象，此階段需要停頓線程，但耗時(shí)很短。

并發(fā)標(biāo)記（Concurrent Marking） ：從GC Root 開始對(duì)堆中對(duì)象進(jìn)行可達(dá)性分析，找到存活對(duì)象，此階段耗時(shí)較長(zhǎng)，但可與用戶程序并發(fā)執(zhí)行。

最終標(biāo)記（Final Marking）：為了修正在并發(fā)標(biāo)記期間因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分標(biāo)記記錄，虛擬機(jī)將這段時(shí)間對(duì)象變化記錄在線程的Remembered Set Logs里面，最終標(biāo)記階段需要把Remembered Set Logs的數(shù)據(jù)合并到Remembered Set中，這階段需要停頓線程，但是可并行執(zhí)行。

篩選回收（Live Data Counting and Evacuation） ：首先對(duì)各個(gè)Region中的回收價(jià)值和成本進(jìn)行排序，根據(jù)用戶所期望的GC 停頓時(shí)間來制定回收計(jì)劃。此階段其實(shí)也可以做到與用戶程序一起并發(fā)執(zhí)行，但是因?yàn)橹换厥找徊糠諶egion，時(shí)間是用戶可控制的，而且停頓用戶線程將大幅度提高收集效率。

總結(jié)

今天給大家介紹了垃圾回收的算法和JVM的垃圾回收器，算法作為思路和方法論的指導(dǎo)，而垃圾回收器是方法論的最佳實(shí)踐，這里通過一張表格將兩者進(jìn)行一個(gè)總結(jié)：

作者介紹

崔皓，51CTO社區(qū)編輯，資深架構(gòu)師，擁有18年的軟件開發(fā)和架構(gòu)經(jīng)驗(yàn)，10年分布式架構(gòu)經(jīng)驗(yàn)。曾任惠普技術(shù)專家。樂于分享，撰寫了很多熱門技術(shù)文章，閱讀量超過60萬(wàn)。《分布式架構(gòu)原理與實(shí)踐》作者。

點(diǎn)分享

點(diǎn)收藏

點(diǎn)點(diǎn)贊

關(guān)鍵詞： 詳解JVM 的垃圾回收算法和垃圾回收器