從原理聊JVM（三）：詳解現(xiàn)代垃圾回收器Shenandoah和ZGC

作者：京東科技 康志興

Shenandoah一詞來自于印第安語，十九世紀(jì)四十年代有一首著名的航海歌曲在水手中廣為流傳，講述一位年輕富商愛上印第安酋長(zhǎng)Shenandoah的女兒的故事。 后來美國(guó)有一條位于Virginia州西部的小河以此命名，所以Shenandoah的中文譯名為“情人渡”。

【資料圖】

Shenandoah首次出現(xiàn)在Open JDK12中，是由Red Hat開發(fā)，主要為了解決之前各種垃圾回收器處理大堆時(shí)停頓較長(zhǎng)的問題。

相比較G1將低停頓做到了百毫秒級(jí)別，Shenandoah的設(shè)計(jì)目標(biāo)是將停頓壓縮到10ms級(jí)別，且與堆大小無關(guān)。它的設(shè)計(jì)非常激進(jìn)，很多設(shè)計(jì)點(diǎn)在權(quán)衡上更傾向于低停頓，而不是高吞吐。

Shenandoah是OpenJDK中的垃圾處理器，但相比較Oracle JDK中根正苗紅的ZGC，Shenandoah可以說更像是G1的繼承者，很多方面與G1非常相似，甚至共用了一部分代碼。

總的來說，Shenandoah和G1有三點(diǎn)主要區(qū)別：

1.G1的回收是需要STW的，而且這部分停頓占整體停頓時(shí)間的80%以上，Shenandoah則實(shí)現(xiàn)了并發(fā)回收。

2.Shenandoah不再區(qū)分年輕代和年老代。

3.Shenandoah使用連接矩陣替代G1中的卡表。

關(guān)于G1的詳細(xì)介紹請(qǐng)翻看前一篇：從原理聊JVM（二）：從串行收集器到分區(qū)收集開創(chuàng)者G1

G1中每個(gè)Region都要維護(hù)卡表，既耗費(fèi)計(jì)算資源還占據(jù)了非常大的內(nèi)存空間，Shenandoah使用了連接矩陣來優(yōu)化了這個(gè)問題。

連接矩陣可以簡(jiǎn)單理解為一個(gè)二維表格，如果Region A中有對(duì)象指向Region B中的對(duì)象，那么就在表格的第A行第B列打上標(biāo)記。

比如，Region 1指向Region 3，Region 4指向Region 2，Region 3指向Region 5：

相比G1的記憶集來說，連接矩陣的顆粒度更粗，直接指向了整個(gè)Region，所以掃描范圍更大。但由于此時(shí)GC是并發(fā)進(jìn)行的，所以這是通過選擇更低資源消耗的連接矩陣而對(duì)吞吐進(jìn)行妥協(xié)的一項(xiàng)決策。

想要達(dá)到并發(fā)回收，就需要在用戶線程運(yùn)行的同時(shí)，將存活對(duì)象逐步復(fù)制到空的Region中，這個(gè)過程中就會(huì)在堆中同時(shí)存在新舊兩個(gè)對(duì)象。那么如何讓用戶線程訪問到新對(duì)象呢？

此前，通常是在舊對(duì)象原有內(nèi)存上設(shè)置保護(hù)陷阱（Memory Protection Trap），當(dāng)訪問到這個(gè)舊對(duì)象時(shí)就會(huì)發(fā)生自陷異常，使程序進(jìn)入到預(yù)設(shè)的異常處理器中，再由處理器中的代碼將訪問轉(zhuǎn)發(fā)到復(fù)制后的新對(duì)象上。

自陷是由線程發(fā)起來打斷當(dāng)前執(zhí)行的程序，進(jìn)而獲得CPU的使用權(quán)。這一操作通常需要操作系統(tǒng)參與，那么就會(huì)發(fā)生用戶態(tài)到內(nèi)核態(tài)的轉(zhuǎn)換，代價(jià)十分巨大。

所以Rodney A.Brooks提出了使用轉(zhuǎn)發(fā)指針來實(shí)現(xiàn)通過舊對(duì)象訪問新對(duì)象的方式：在對(duì)象頭前面增加一個(gè)新的引用字段，在非并發(fā)移動(dòng)情況下指向自己，產(chǎn)生新對(duì)象后指向新對(duì)象。那么當(dāng)訪問對(duì)象的時(shí)候，都需要先訪問轉(zhuǎn)發(fā)指針看看其指向哪里。雖然和內(nèi)存自陷方案相比同樣需要多一次訪問轉(zhuǎn)發(fā)的開銷，但是前者消耗小了很多。

轉(zhuǎn)發(fā)指針主要存在兩個(gè)問題：修改時(shí)的線程安全問題和高頻訪問的性能問題。

1.對(duì)象體增加了一個(gè)轉(zhuǎn)發(fā)指針，這個(gè)指針的修改和對(duì)象本身的修改就存在了線程安全問題。如果通過被訪問就可能發(fā)生復(fù)制了新對(duì)象后，轉(zhuǎn)發(fā)對(duì)象修改之前發(fā)生了舊對(duì)象的修改，這就存在兩個(gè)對(duì)象不一致的問題了。對(duì)于這個(gè)問題，Shenandoah是通過CAS操作來保證修改正確性的。

2.轉(zhuǎn)發(fā)指針的加入需要覆蓋所有對(duì)象訪問的場(chǎng)景，包括讀、寫、加鎖等等，所以需要同時(shí)設(shè)置讀屏障和寫屏障。尤其讀操作相比單純寫操作出現(xiàn)頻率更高，這樣高頻操作帶來的性能問題影響巨大。所以Shenandoah在JDK13中對(duì)此進(jìn)行了優(yōu)化，將內(nèi)存屏障模型改為引用訪問屏障，也就是說，僅僅在對(duì)象中引用類型的讀寫操作增加屏障，而不去管原生對(duì)象的操作，這就省去了大量的對(duì)象訪問操作。

標(biāo)記與GC Roots直接關(guān)聯(lián)的對(duì)象。

遍歷對(duì)象圖，標(biāo)記全部可達(dá)對(duì)象。

處理剩余的SATB掃描，并在這個(gè)階段統(tǒng)計(jì)出回收價(jià)值最高的Region，將這些Region構(gòu)成一組回收集。

回收所有不包含任何存活對(duì)象的Region（這類Region被稱為Immediate Garbage Region）。

將回收集里面的存貨對(duì)象復(fù)制到一個(gè)其他未被使用的Region中。并發(fā)復(fù)制存活對(duì)象，就會(huì)在同一時(shí)間內(nèi)，同一對(duì)象在堆中存在兩份，那么就存在該對(duì)象的讀寫一致性問題。Shenandoah通過使用轉(zhuǎn)發(fā)指針將舊對(duì)象的請(qǐng)求指向新對(duì)象解決了這個(gè)問題。這也是Shenandoah和其他GC最大的不同。

并發(fā)回收后，需要將所有指向舊對(duì)象的引用修正到新對(duì)象上。這個(gè)階段實(shí)際上并沒有實(shí)際操作，只是設(shè)置一個(gè)阻塞點(diǎn)來保證上述并發(fā)操作均已完成。

順著內(nèi)存物理地址線性遍歷堆空間，更新并發(fā)回收階段復(fù)制的對(duì)象的引用。

堆空間中的引用更新完畢后，最后需要修正GC Roots中的引用。

此時(shí)回收集中Region應(yīng)該全部變成Immediate Garbage Region了，再次執(zhí)行并發(fā)清理，將這些Region全部回收。

ZGC是Oracle官方研發(fā)并JDK11中引入，并于JDK15中作為生產(chǎn)就緒使用，其設(shè)計(jì)之初定義了三大目標(biāo)：

1.支持TB級(jí)內(nèi)存

2.停頓控制在10ms以內(nèi)，且不隨堆大小增加而增加

3.對(duì)程序吞吐量影響小于15%

隨著JDK的迭代，目前JDK16及以上版本，ZGC已經(jīng)可以實(shí)現(xiàn)不超過1毫秒的停頓，適用于堆大小在8MB到16TB之間。

ZGC和G1一樣也采用了分區(qū)域的堆內(nèi)存布局，不同的是，ZGC的Region（官方稱為Page，概念同G1的Region）可以動(dòng)態(tài)創(chuàng)建和銷毀，容量也可以動(dòng)態(tài)調(diào)整。

ZGC的Region分為三種：

1.小型Region容量固定為2MB，用于存放小于256KB的對(duì)象。

2.中型Region容量固定為32MB，用于存放大于等于256KB但不足4MB的對(duì)象。

3.大型Region容量為2MB的整數(shù)倍，存放4MB及以上大小的對(duì)象，而且每個(gè)大型Region中只存放一個(gè)大對(duì)象。由于大對(duì)象移動(dòng)代價(jià)過大，所以該對(duì)象不會(huì)被重分配。

G1中的回收集用來存放所有需要G1掃描的Region，而ZGC為了省去卡表的維護(hù)，標(biāo)記過程會(huì)掃描所有Region，如果判定某個(gè)Region中的存活對(duì)象需要被重分配，那么就將該Region放入重分配集中。

通俗的說，如果將GC分為標(biāo)記和回收兩個(gè)主要階段，那么回收集是用來判定標(biāo)記哪些Region，重分配集用來判定回收哪些Region。

和Shenandoah相同，ZGC也實(shí)現(xiàn)了并發(fā)回收，不同的是前者是使用轉(zhuǎn)發(fā)指針來實(shí)現(xiàn)的，后者則是采用染色指針的技術(shù)來實(shí)現(xiàn)。

三色標(biāo)記本質(zhì)上與對(duì)象無關(guān)，僅僅與引用有關(guān)：通過引用關(guān)系判定對(duì)像存活與否。HotSpot虛擬機(jī)中不同垃圾回收器有著不同的處理方式，有些是標(biāo)記在對(duì)象頭中，有些是標(biāo)記在單獨(dú)的數(shù)據(jù)結(jié)構(gòu)中，而ZGC則是直接標(biāo)記在指針上。

64位機(jī)器指針是64位，Linux下64位中高18位不能用來尋址，剩下46位中，ZGC選擇其中4位用來輔助GC工作，另外42位能夠支持最大內(nèi)存為4T，通常來說，4T的內(nèi)存完全夠用。

具體來說，ZGC在指針中增加了4個(gè)標(biāo)志位，包括Finalizable、Remapped、Marked 0和Marked 1。

源碼注釋如下：

6                 4 4 4  4 4                                             0 3                 7 6 5  2 1                                             0+-------------------+-+----+-----------------------------------------------+|00000000 00000000 0|0|1111|11 11111111 11111111 11111111 11111111 11111111|+-------------------+-+----+-----------------------------------------------+|                   | |    ||                   | |    * 41-0 Object Offset (42-bits, 4TB address space)|                   | ||                   | * 45-42 Metadata Bits (4-bits)  0001 = Marked0|                   |                                 0010 = Marked1|                   |                                 0100 = Remapped|                   |                                 1000 = Finalizable|                   ||                   * 46-46 Unused (1-bit, always zero)|* 63-47 Fixed (17-bits, always zero)

Finalizable標(biāo)識(shí)表示對(duì)象是否只能通過finalize()方法訪問到，Remapped、Marked 0和Marked 1用作三色標(biāo)記（后面簡(jiǎn)稱為M0和M1）。

為什么既有M0還有M1呢？

因?yàn)閆GC標(biāo)記完成后并不需要等待對(duì)象指針重映射就可以進(jìn)行下一次垃圾回收循環(huán)，也就是說兩次垃圾回收的全過程是有重疊的，所以使用兩個(gè)標(biāo)記位分別用作兩次相鄰GC過程的標(biāo)記，M0和M1交替使用。

我們通過紅藍(lán)黃三個(gè)顏色分別表示三種標(biāo)記狀態(tài)：

1.第一次標(biāo)記開始時(shí)所有的指針都處于Remapped狀態(tài)

整個(gè)標(biāo)記過程中新分配到對(duì)象都被直接標(biāo)記為M0，比如對(duì)象D。

復(fù)制完成的對(duì)象，指針就可以由M0改為Remapped，并將舊對(duì)象到新對(duì)象到映射關(guān)系保存到轉(zhuǎn)發(fā)表中。

這個(gè)行為稱為指針的“自愈”。

實(shí)際上，如果沒有對(duì)象D的存在，在上一步所有存貨對(duì)象轉(zhuǎn)移完成后，舊的Page就可以被回收了，依靠指針和轉(zhuǎn)發(fā)表就可以將所有訪問轉(zhuǎn)發(fā)到新的Page中去。

可以看出，并發(fā)標(biāo)記的過程中，ZGC是通過讀屏障來保證訪問的正確轉(zhuǎn)發(fā)，并且由于染色指針采用惰性更新的策略，相比Shenandoah每次都要先訪問轉(zhuǎn)發(fā)指針的兩次尋址來說快上不少。

1.由于染色指針提供的“自愈”能力，當(dāng)某個(gè)Page被清除后可以立刻被回收，而無需等待修正全部指向該P(yáng)age的引用。

2.ZGC完全不需要使用寫屏障，原因有二：由于使用染色指針，無需更新對(duì)象體；沒有分代所以無需記錄跨代引用。

3.染色指針并未完全開發(fā)使用，剩下的18位提供了非常大的擴(kuò)展性。

而染色指針有一個(gè)天然的問題，就是操作系統(tǒng)和處理器并不完全支持程序?qū)χ羔樀男薷摹?/p>多種內(nèi)存映射

染色指針只是JVM定義的，操作系統(tǒng)、處理器未必支持。為了解決這個(gè)問題，ZGC在Linux/x86-64平臺(tái)上采用了虛擬內(nèi)存映射技術(shù)。

ZGC為每個(gè)對(duì)象都創(chuàng)建了三個(gè)虛擬內(nèi)存地址，分別對(duì)應(yīng)Remapped、Marked 0和Marked 1，通過指針指向不同的虛擬內(nèi)存地址來表示不同的染色標(biāo)記。

ZGC沒有分代，這一點(diǎn)并不是技術(shù)權(quán)衡，而是基于工作量的考慮。所以目前來看，整體的GC效率還有很大提升空間。

ZGC使用了讀屏障來完成指針的“自愈”，由于ZGC目前沒有分代，且ZGC通過掃描所有Region來省去卡表使用，所以ZGC并沒有寫屏障，這成為ZGC一大性能優(yōu)勢(shì)。

多核CPU同時(shí)操作內(nèi)存就會(huì)發(fā)生爭(zhēng)搶，現(xiàn)代CPU把內(nèi)存控制系統(tǒng)器集成到處理器內(nèi)核中，每個(gè)CPU核心都有屬于自己的本地內(nèi)存。

在NUMA架構(gòu)下，ZGC會(huì)有現(xiàn)在自己的本地內(nèi)存上分配對(duì)象，避免了內(nèi)存使用的競(jìng)爭(zhēng)。

在ZGC之前，只有Parallet Scavenge支持NUMA內(nèi)存分配。

ZGC和Shenadoah一樣，幾乎所有運(yùn)行階段都和用戶線程并發(fā)進(jìn)行。其中同樣包含初始標(biāo)記、重新標(biāo)記等STW的過程，作用相同，不再贅述。重點(diǎn)介紹以下四個(gè)并發(fā)階段：

并發(fā)標(biāo)記階段和G1相同，都是遍歷對(duì)象圖進(jìn)行可達(dá)性分析，不同的是ZGC的標(biāo)記在染色指針上。

在這個(gè)階段，ZGC會(huì)掃描所有Region，如果哪些Region里面的存活對(duì)象需要被分配的新的Region中，就將這些Region放入重分配集中。

此外，JDK12后ZGC的類卸載和弱引用的處理也在這個(gè)階段。

ZGC在這個(gè)階段會(huì)將重分配集里面的Region中的存貨對(duì)象復(fù)制到一個(gè)新的Region中，并為重分配集中每一個(gè)Region維護(hù)一個(gè)轉(zhuǎn)發(fā)表，記錄舊對(duì)象到新對(duì)象的映射關(guān)系。

如果在這個(gè)階段用戶線程并發(fā)訪問了重分配過程中的對(duì)象，并通過指針上的標(biāo)記發(fā)現(xiàn)對(duì)象處于重分配集中，就會(huì)被讀屏障截獲，通過轉(zhuǎn)發(fā)表的內(nèi)容轉(zhuǎn)發(fā)該訪問，并修改該引用的值。

ZGC將這種行為稱為自愈（Self-Healing），ZGC的這種設(shè)計(jì)導(dǎo)致只有在訪問到該指針時(shí)才會(huì)觸發(fā)一次轉(zhuǎn)發(fā)，比Shenandoah的轉(zhuǎn)發(fā)指針每次都要轉(zhuǎn)發(fā)要好得多。

另一個(gè)好處是，如果一個(gè)Region中所有對(duì)象都復(fù)制完畢了，該Region就可以被回收了，只要保留轉(zhuǎn)發(fā)表即可。

最后一個(gè)階段的任務(wù)就是修正所有的指針并釋放轉(zhuǎn)發(fā)表。

這個(gè)階段的迫切性不高，所以ZGC將并發(fā)重映射合并到在下一次垃圾回收循環(huán)中的并發(fā)標(biāo)記階段中，反正他們都需要遍歷所有對(duì)象。

現(xiàn)代的垃圾回收器為了低停頓的目標(biāo)可謂將“并發(fā)”二字玩到極致，Shenandoah在G1基礎(chǔ)上做了非常多的優(yōu)化來使回收階段并行，而ZGC直接采用了染色指針、NUMA等黑科技，目的都是為了讓Java開發(fā)者可以更多的將精力放在如何使用對(duì)象讓程序更好的運(yùn)行，剩下的一切交給GC，我們所做的只需享受現(xiàn)代化GC技術(shù)帶來的良好體驗(yàn)。

1.?OpenJDK 17 中的 Shenandoah：亞毫秒級(jí) GC 停頓【譯】 - 知乎 (zhihu.com)

2.?https://shipilev.net/talks/devoxx-Nov2017-shenandoah.pdf

3.?https://openjdk.java.net/jeps/333

標(biāo)簽：

　　 原標(biāo)題：從原理聊JVM（三）：詳解現(xiàn)代垃圾回收器Shenandoah和ZGC