新一代垃圾回收器ZGC設計與實現

1、G1的三大缺點：垃圾回收時間長，幾百毫秒；內存利用率低，有1-20%的空間浪費；最多支持100G內存，不夠用。 ZGC的第一個優化就是優化回收時間，G1的回收時間有80%浪費在複製算法上，這個算法需要STW，ZGC要打破這個停頓，變成並行的。 2、支持的內存大小 （1）G1其實指針的長度是夠的，但是G1用空間換時間，對現有內存維護一個RSet來記錄，這部分佔了20%的內存；而且G1需要STW，這部分性能會有問題；所以大內存撐不了，主要還是性能。 （2）ZGC只能支持4T的原因：目前用到的虛擬指針位只有46位，理論上最大能用48位。這是由於X86_64處理器硬件的限制，目前X86_64處理器地址線只有48條，軟件的處理集上可以支持64位，但實際上硬件只有48位能用。 3、GC觸發的時機 （1）固定頻率觸發 （2）按照已經發生的垃圾回收時間，預測下一次垃圾回收的時間 4、垃圾回收的過程： 大的思路是先標記、後複製、在下一個流程裏面把持有引用的對象引用地址更新掉； （1）初始標記階段，這時候Remapped裏面是上一次回收結束之後的存活對象，類似於S2區域。 選定M0當做本次的S1，標記期間的新對象都標記成存活對象；這個階段結束之後，存活對象都在M0標記裏了 （2）剩下的M1和Remapped就是垃圾，進入併發轉移階段 按照每個頁面的垃圾排序，把M0裏的存活對象標記成Remapped，並且把對象換個物理頁面；如果遍歷到的頁面上某個對象是Remapped，那就是垃圾了，不會是自己剛改寫的 物理頁面裏的存活對象轉移完了之後，頁面就能回收了，如果不回收，也把裏面的對象標記成Remapped 併發轉移結束之後，存活對象都在Remapped裏面，有些是垃圾但是不回收的，也在Remapped裏面。 （3）轉移之後引用的改寫： 轉移之前，把引用映射Map置成null 轉移的時候，每移動一個對象，就把這個對象轉移前後的地址都放在映射Map裏面，轉移結束之後實際上新對象裏的持有引用可能還是舊的 存活對象轉移之前，指針標記是M0，這時候有用戶線程過來訪問，會觸發讀屏障，先幫忙進行轉移 轉移之後，指針標記是Remapped，這時候用戶線程過來訪問，會去引用映射Map裏面更新自己的持有引用地址；如果一直沒有用戶線程訪問，拖到標記階段，標記線程也會做這件事

2024.No41： 24年第18本技術書。2019年出版，很可能是關於ZGC的第一本中文書。講述關於ZGC的方方面面：內存管理、線程、垃圾回收算法、日誌解析、參數設置、基準測試、編譯調試，以及Shenandoah GC。值得反覆翻閱。 5年過去，JDK22已然發佈，相信有更多關於ZGC的優化和改進。 希望看到第二版。

介紹zgc全面，並且對於算法具體實現的原因給予解釋。

對ZGC的介紹很詳實。 令人耳目一新的是，作者爲了更好地描述ZGC整個流程，先從設計思路上爲讀者理清了一些基本概念，這樣讓讀者不光知其然更知其所以然。 需要好好消化。

內容詳實 講解了zgc算法的細節 內存管理  以及linux內存分配的背景

回收部分講的挺細緻的，源碼和調試那塊基本都帶過，看不太懂…

這本書短小精悍，把ZGC講得很詳細，值得一看

深入瞭解了ZGC垃圾回收處理器和G1的不同，爲以後升級做準備

講的比較清楚，是研究ZGC非常好的資料

這類書的通病，設計講的不咋地，反正就是懟源碼。。