本文部分摘自《深入理解 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 把併發重對映階段要做的工作，合併到下一次垃圾收集迴圈中的併發標記階段去完成，反正都是要遍歷所有物件圖，這樣還可以節省一次遍歷物件圖的開銷。一旦所有指標被修正之後，原來記錄新舊物件關係的轉發表就可以釋放掉了