本文部分摘自《深入理解 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 把并發重映射階段要做的作業，合并到下一次垃圾收集回圈中的并發標記階段去完成，反正都是要遍歷所有物件圖，這樣還可以節省一次遍歷物件圖的開銷，一旦所有指標被修正之后，原來記錄新舊物件關系的轉發表就可以釋放掉了
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/243111.html
標籤：Java