作者：京東科技 康志興

Shenandoah

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

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

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

“G1的繼承者”

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

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

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

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

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

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

連接矩陣（Connection Matrix）

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

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

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

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

轉(zhuǎn)發(fā)指針

轉(zhuǎn)發(fā)指針的性能優(yōu)勢

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

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

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

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

轉(zhuǎn)發(fā)指針的問題

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

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

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

Shenandoah的運行步驟

1. 初始標(biāo)記（Init Mark）[STW] [同G1]

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

2. 并發(fā)標(biāo)記（Concurrent Marking）[同G1]

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

3. 最終標(biāo)記（Final Mark）[STW] [同G1]

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

4. 并發(fā)清理（Concurrent Cleanup）

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

5. 并發(fā)回收（Concurrent Evacuation）

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

6. 初始引用更新（Init Update References）[STW]

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

7. 并發(fā)引用更新（Concurrent Update References）

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

8. 最終引用更新（Final Update References）[STW]

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

9. 并發(fā)清理（Concurrent Cleanup）

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

ZGC

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

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

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

3.對程序吞吐量影響小于15%

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

ZGC的內(nèi)存布局

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

ZGC的Region分為三種：

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

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

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

重分配集（Relocation Set）

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

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

染色指針

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

三色標(biāo)記本質(zhì)上與對象無關(guān)，僅僅與引用有關(guān)：通過引用關(guān)系判定對像存活與否。HotSpot虛擬機(jī)中不同垃圾回收器有著不同的處理方式，有些是標(biāo)記在對象頭中，有些是標(biāo)記在單獨的數(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個標(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)識表示對象是否只能通過finalize()方法訪問到，Remapped、Marked 0和Marked 1用作三色標(biāo)記（后面簡稱為M0和M1）。

為什么既有M0還有M1呢？

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

染色指針的在GC過程中的作用

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

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

2. 從GC Root開始，順著對象圖遍歷掃描，存活對象標(biāo)記為M0

3. 標(biāo)記完成后，開始進(jìn)行并發(fā)重分配。最終目標(biāo)是將A、B、C三個存活對象都移動到新的Region中去。

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

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

4. 如果此時系統(tǒng)訪問對象C，會觸發(fā)讀屏障，將原引用修正到新的對象C的地址上去，并轉(zhuǎn)發(fā)訪問，最后刪除轉(zhuǎn)發(fā)表的記錄。

這個行為稱為指針的“自愈”。

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

5. 并發(fā)重映射階段會把所有引用修正，并刪除轉(zhuǎn)發(fā)表的記錄。

6. 下一次并發(fā)標(biāo)記開始后，由于上一次垃圾回收循環(huán)并沒有完成，所以Remapped指針被標(biāo)記為M1，用來和上一次的存活對象標(biāo)記作區(qū)分。

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

染色指針的三大優(yōu)點

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

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

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

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

多種內(nèi)存映射

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

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

分代

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

讀屏障

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

NUMA

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

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

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

ZGC的運行步驟

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

并發(fā)標(biāo)記

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

并發(fā)預(yù)備重分配

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

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

并發(fā)重分配

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

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

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

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

并發(fā)重映射

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

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

總結(jié)

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

參考：

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

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

3.?https://openjdk.java.net/jeps/333文章來源地址http://www.zghlxwxcb.cn/news/detail-426735.html

到了這里，關(guān)于從原理聊JVM（三）：詳解現(xiàn)代垃圾回收器Shenandoah和ZGC的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！