JVM 低延遲垃圾收集器 Shenandoah 和 ZGC
本文部分摘自《深入理解 Java 虛擬機第三版》
概述
衡量垃圾收集器的三項指標分別是：內存佔用、吞吐量和延遲。這三者共同構成一個「不可能三角」，即一款優秀的收集器最多可以同時達成其中兩項
隨着硬件性能的提升，對內存佔用和吞吐量也有所助益，但對延遲卻並非如此。比如內存擴大了，對延遲反而會帶來負面效果，因為回收 1TB 的堆內存毫無疑問會比回收 1GB 的堆內存耗費更多時間。因此，延遲成為了垃圾收集器最重視的性能指標
在 CMS 和 G1 之前的全部收集器，其工作的所有步驟都會產生 Stop The World。CMS 和 G1 分別使用增量更新和原始快照技術，實現了標記階段的並發，但對標記後的清理仍未得到妥善解決。CMS 使用標記 – 清除算法，雖然可與用戶線程並發執行，但會產生空間碎片，一旦碎片淤積過多就必然會 Stop The World。G1 雖然可以按更小粒度進行回收，但會出現短暫的停頓
本文要介紹的兩款收集器：Shenandoah 和 ZGC，幾乎整個工作過程都是並發的，只有初始標記、最終標記階段有短暫的停頓，並且停頓時間基本固定，與堆的容量、對象數量無關。這兩款目前仍處於實驗狀態的收集器，被官方命名為低延遲垃圾收集器
Shenandoah 收集器
Shenandoah 作為一款第一個不由 Oracle 開發的 HotSpot 收集器，被官方明確拒絕在 OracleJDK12 中支持 Shenandoah 收集器，因此 Shenandoah 收集器只在 OpenJDK 才會包含。Shenandoah 收集器能實現在任何堆內存大小下都把垃圾停頓時間限制在十毫秒以內，這意味着相比 CMS 和 G1，Shenandoah 不僅要進行並發的垃圾標記，還要並發低進行對象清理後的整理
Shenandoah 和 G1 有相似的堆內存布局，在初始標記、並發標記等許多階段的處理思路都高度一致，甚至直接共享一部分代碼。不同的是，雖然 Shenandoah 也是基於 Region 的堆內存布局，回收策略也和 G1 一致，但在管理堆內存方面，它與 G1 至少有三個明顯的不同：
- 支持並發的整理算法，G1 的回收階段可以多線程並行，但不能與用戶線程並發
- Shenandoah 默認不使用分代收集
- Shenandoah 摒棄了在 G1 中需耗費大量資源去維護的記憶集，改用連接矩陣的全局數據結構來記錄跨 Region 的引用關係
SHenandoah 收集器的工作過程大致可分為以下九個階段：
-
初始標記
首先標記與 GC Roots 直接關聯的對象，需要 Stop The World
-
並發標記
遍歷對象圖，標記出全部可達對象，這個階段與用戶線程一起並發執行
-
最終標記
處理剩餘的 SATB 掃描，並統計出回收價值最高的 Region，並構成一組回收集，該階段會有短暫停頓
-
並發清理
這個階段用於清理那些整個區域內連一個存活對象都沒有找到的 Region
-
並發回收
把回收集裏面的存活對象先複製一份到其他未被使用的 Region，並發執行的困難在於移動對象的同時，用戶線程可能會對移動對象進行讀寫訪問，移動對象是一次性行為，但移動之後整個內存中所有指向對象的引用還是舊對象的地址，還難在一瞬間全部改變過來。Shenandoah 將會通過讀屏障和被稱為 Brooks Pointers 的轉髮指針來解決
-
初始引用更新
並發回收複製對象結束後，還需把堆中所有指向舊對象的引用修正到複製後的新對象，這個操作稱為引用更新。引用更新的初始化階段實際上並沒有做什麼具體處理，只是為了建立一個線程集合點，確保所有並發回收階段中進行的收集器線程都已經完成分配給它們的對象移動任務，會有短暫的停頓
-
並發引用更新
真正開始引用更新操作，與並發標記不同，它不再需要沿着對象圖來搜索，只需按照內存物理地址的順序，線性地搜索出引用類型，把舊值改為新值
-
最終引用更新
修正 GC Roots 中的引用，這個階段是 Shenandoah 的最後一次停頓
-
並發清理
經過並發回收和引用更新後，整個回收集中所有的 Region 已無存活對象，最後一次並發清理回收這些 Region 的內存空間，供新對象分配使用
了解了 Shenandoah 收集器的工作過程，再來看一下 Shenandoah 用於支持並發整理的核心概念 —— 轉髮指針（Brooks Pointer）。此前，要做類似的並發操作，通常要在被移動對象原有的內存上設置保護指針，一旦用戶程序訪問到歸屬於舊對象的內存空間就會產生自陷中斷，進入預設好的異常處理器，再由其中的代碼邏輯把訪問轉發到複製後的新對象。這種方式雖然能實現對象移動和用戶線程並發，但如果沒有操作系統層面的直接支持，將導致用戶態頻繁切換到核心態，代價巨大
轉髮指針是在原有對象布局結構的最前面統一增加一個新的引用字段，在正常情況下，該引用指向對象自己。當對象擁有一份新的副本時，只需修改一處指針的值，即舊對象上轉髮指針的引用位置，使其指向新對象，便可將所有對該對象的訪問轉發到新的副本上。這樣只要舊對象的內存仍然存在，虛擬機內存中所有通過舊地址訪問的代碼仍可繼續使用，都會被轉發到新對象繼續工作
ZGC 收集器
ZGC 全稱 Z Garbage Collector，是一款在 JDK11 新加入的具有實驗性質的低延遲垃圾收集器，由 Oracle 公司研發。ZGC 與 Shenandoah 的目標高度相似，都希望在對吞吐量影響不大的前提下，實現任意堆內存大小下垃圾收集停頓時間限制在十毫秒以內，但兩者的實現思路又有顯著差異。ZGC 是一款基於 Region 內存布局的，不設分代的，使用讀屏障、染色指針和內存多重映射等技術來實現可並發的標記 – 整理算法的，以低延遲為首要目標的一款垃圾收集器
首先從 ZGC 的內存布局說起，ZGC 的 Region 具有動態性，即動態創建和銷毀，以及動態的區域容量大小。然後是 ZGC 的並發整理算法的實現，ZGC 採用的是染色指針技術（Colored Pointer）。從前，如果我們要在對象上存儲一些額外信息，通常會在對象頭中增加額外的存儲字段，如哈希碼、分代年齡、鎖記錄等。這種方式在有對象訪問的場景下是很自然流程的，不會有問題，但如果對象存在被移動過的可能性，即不能保證能成功訪問對象呢？又或者有一些根本就不會訪問對象，但又希望得知對象的某些信息的場景呢？能不能從指針或者與對象內存無關的地方獲取這些信息呢？
染色指針是一種直接將少量額外信息存儲在指針上的技術，ZGC 甚至直接把標記階段的標記信息記錄在引用對象的指針上，因此，與其說可達性分析是遍歷對象圖來標記對象，不如說是遍歷引用圖來標記引用。使用染色指針有三大優勢：
- 染色指針可以使得某一 Region 的存活對象被移走之後，該 Region 能立即被釋放和重用，而不必等待整個堆中所有指向該 Region 的引用都被修正才能清理
- 染色指針可以直接記錄對象引用的變動信息，減少內存屏障（尤其是寫屏障）的使用
- 染色指針可以作為一種可擴展的存儲結構，用來記錄更多與對象標記、重定位相關的數據
ZGC 的運行過程大致可劃分為以下四個大的階段，都是可以並發執行的，僅是兩個階段中間會存在短暫的停頓小階段：
-
並發標記（Concurrent Mark）
遍歷對象圖做可達性分析，前後也要經歷類似 G1、Shenandoah 的初始標記、最終標記的短暫停頓。與 G1、Shenandoah 不同的是，ZGC 的標記是在指針上而非對象，標記階段會更新染色指針中的 Marked 0、Marked 1 標誌位
-
並發預備重分配（Concurrent Prepare for Relocate）
根據特定的查詢條件統計出本次收集過程要清理哪些 Region，將這些 Region 組成重分配集（Relocation Set）。ZGC 劃分 Region 的目的並非像 G1 是為了做收益優先的增量回收，ZGC 每次回收都會掃描所有 Region，用範圍更大的掃描成本換取維護記憶集的成本。ZGC 的標記過程是針對全堆的，ZGC 的重分配集只是決定裏面的存活對象會被重新複製到其他的 Region 中，裏面的 Region 會被釋放，而不能說回收行為就只針對這個集合裏面的 Region
-
並發重分配（Concurrent Relocate）
這個過程要把重分配集中的存活對象複製到新的 Region 上，並為重分配集中的每個 Region 維護一個轉發表，記錄從舊對象到新對象的轉發關係。如果用戶線程此時並發訪問位於重分配集中的對象，這次訪問將會被預置的內存屏障所截獲，並根據 Region 上的轉發表記錄將訪問轉發到新複製的對象上，同時更新該引用的值，使其指向新對象，這種行為稱為指針的自愈（Self-Healing）能力
-
並發重映射（Concurrent Remap）
修正整個堆中指向重分配集中舊對象的所有引用，不過這並不是一項迫切完成的任務，因為即使是舊引用，它也是可以自愈的。因此，ZGC 把並發重映射階段要做的工作，合併到下一次垃圾收集循環中的並發標記階段去完成，反正都是要遍歷所有對象圖，這樣還可以節省一次遍歷對象圖的開銷。一旦所有指針被修正之後，原來記錄新舊對象關係的轉發表就可以釋放掉了
