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

作者：京東科技 康志興

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

【資料圖】

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

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

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

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

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

2.Shenandoah不再區分年輕代和年老代。

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

關于G1的詳細介紹請翻看前一篇：從原理聊JVM（二）：從串行收集器到分區收集開創者G1

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

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

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

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

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

此前，通常是在舊對象原有內存上設置保護陷阱（Memory Protection Trap），當訪問到這個舊對象時就會發生自陷異常，使程序進入到預設的異常處理器中，再由處理器中的代碼將訪問轉發到復制后的新對象上。

自陷是由線程發起來打斷當前執行的程序，進而獲得CPU的使用權。這一操作通常需要操作系統參與，那么就會發生用戶態到內核態的轉換，代價十分巨大。

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

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

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

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

標記與GC Roots直接關聯的對象。

遍歷對象圖，標記全部可達對象。

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

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

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

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

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

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

此時回收集中Region應該全部變成Immediate Garbage Region了，再次執行并發清理，將這些Region全部回收。

ZGC是Oracle官方研發并JDK11中引入，并于JDK15中作為生產就緒使用，其設計之初定義了三大目標：

1.支持TB級內存

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

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

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

ZGC和G1一樣也采用了分區域的堆內存布局，不同的是，ZGC的Region（官方稱為Page，概念同G1的Region）可以動態創建和銷毀，容量也可以動態調整。

ZGC的Region分為三種：

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

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

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

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

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

和Shenandoah相同，ZGC也實現了并發回收，不同的是前者是使用轉發指針來實現的，后者則是采用染色指針的技術來實現。

三色標記本質上與對象無關，僅僅與引用有關：通過引用關系判定對像存活與否。HotSpot虛擬機中不同垃圾回收器有著不同的處理方式，有些是標記在對象頭中，有些是標記在單獨的數據結構中，而ZGC則是直接標記在指針上。

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

具體來說，ZGC在指針中增加了4個標志位，包括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標識表示對象是否只能通過finalize()方法訪問到，Remapped、Marked 0和Marked 1用作三色標記（后面簡稱為M0和M1）。

為什么既有M0還有M1呢？

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

我們通過紅藍黃三個顏色分別表示三種標記狀態：

1.第一次標記開始時所有的指針都處于Remapped狀態

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

復制完成的對象，指針就可以由M0改為Remapped，并將舊對象到新對象到映射關系保存到轉發表中。

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

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

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

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

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

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

而染色指針有一個天然的問題，就是操作系統和處理器并不完全支持程序對指針的修改。

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

ZGC為每個對象都創建了三個虛擬內存地址，分別對應Remapped、Marked 0和Marked 1，通過指針指向不同的虛擬內存地址來表示不同的染色標記。

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

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

多核CPU同時操作內存就會發生爭搶，現代CPU把內存控制系統器集成到處理器內核中，每個CPU核心都有屬于自己的本地內存。

在NUMA架構下，ZGC會有現在自己的本地內存上分配對象，避免了內存使用的競爭。

在ZGC之前，只有Parallet Scavenge支持NUMA內存分配。

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

并發標記階段和G1相同，都是遍歷對象圖進行可達性分析，不同的是ZGC的標記在染色指針上。

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

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

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

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

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

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

最后一個階段的任務就是修正所有的指針并釋放轉發表。

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

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

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

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

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

標簽：

　　 原標題：從原理聊JVM（三）：詳解現代垃圾回收器Shenandoah和ZGC