Java之CMS GC的7個階段

CMS收集器的主要設計目標是：低應用停頓時間。它經過兩種方式實現這一目標：

1. 不壓縮老年代，而是使用空閒列表來管理回收空間。
2. 大部分標記清理工做與應用程序併發執行。

主要問題：因爲不壓縮帶來的老年代堆碎片，或者在對象分配率高的狀況下，均可能致使Full GC。

CMS收集器的GC週期主要由7個階段組成，其中有兩個階段會發生stop-the-world，其餘階段都是併發執行的。（亦有4個階段、6個階段等說法）

Phase 1: Initial Mark（初始化標記）

初始化標記階段，是CMS GC的第一個階段，也是標記階段的開始。主要工做是標記可直達的存活對象。

主要標記過程

• 從GC Roots遍歷可直達的老年代對象；
• 遍歷被新生代存活對象所引用的老年代對象。

程序執行狀況

• 支持單線程或並行標記。
• 發生stop-the-world，暫停全部應用線程。

（Marked obj：老年代綠色圓點表示被初始化標記的對象。）

Phase 2: Concurrent Mark（併發標記）

併發標記階段，是CMS GC的第二個階段。

在該階段，GC線程和應用線程將併發執行。也就是說，在第一個階段（Initial Mark）被暫停的應用線程將恢復運行。

併發標記階段的主要工做是，經過遍歷第一個階段（Initial Mark）標記出來的存活對象，繼續遞歸遍歷老年代，並標記可直接或間接到達的全部老年代存活對象。

（Current obj：該對象的引用關係發生變化，對下一個對象的引用被刪除。）

因爲在併發標記階段，應用線程和GC線程是併發執行的，所以可能產生新的對象或對象關係發生變化，例如：

• 新生代的對象晉升到老年代；
• 直接在老年代分配對象；
• 老年代對象的引用關係發生變動；
• 等等。

對於這些對象，須要從新標記以防止被遺漏。爲了提升從新標記的效率，本階段會把這些發生變化的對象所在的Card標識爲Dirty，這樣後續就只須要掃描這些Dirty Card的對象，從而避免掃描整個老年代。

Phase 3: Concurrent Preclean（併發預清理）

在併發預清洗階段，將會從新掃描前一個階段標記的Dirty對象，並標記被Dirty對象直接或間接引用的對象，而後清除Card標識。

標記被Dirty對象直接或間接引用的對象：

清除Dirty對象的Card標識：

Phase 4: Concurrent Abortable Preclean（可停止的併發預清理）

本階段儘量承擔更多的併發預處理工做，從而減輕在Final Remark階段的stop-the-world。

在該階段，主要循環的作兩件事：

• 處理 From 和 To 區的對象，標記可達的老年代對象；
• 和上一個階段同樣，掃描處理Dirty Card中的對象。

具體執行多久，取決於許多因素，知足其中一個條件將會停止運行：

• 執行循環次數達到了閾值；
• 執行時間達到了閾值；
• 新生代Eden區的內存使用率達到了閾值。

Phase 5: Final Remark（從新標記）

預清理階段也是併發執行的，並不必定是全部存活對象都會被標記，由於在併發標記的過程當中對象及其引用關係還在不斷變化中。

所以，須要有一個stop-the-world的階段來完成最後的標記工做，這就是從新標記階段（CMS標記階段的最後一個階段）。主要目的是從新掃描以前併發處理階段的全部殘留更新對象。

主要工做：

• 遍歷新生代對象，從新標記；（新生代會被分塊，多線程掃描）
• 根據GC Roots，從新標記；
• 遍歷老年代的Dirty Card，從新標記。這裏的Dirty Card，大部分已經在Preclean階段被處理過了。

Phase 6: Concurrent Sweep（併發清理）

併發清理階段，主要工做是清理全部未被標記的死亡對象，回收被佔用的空間。

Phase 7: Concurrent Reset（併發重置）

併發重置階段，將清理並恢復在CMS GC過程當中的各類狀態，從新初始化CMS相關數據結構，爲下一個垃圾收集週期作好準備。

---

參考

docs.oracle.com/javase/8/do…

blogs.oracle.com/poonam/unde…

blogs.oracle.com/jonthecolle…

plumbr.io/handbook/ga…

www.jianshu.com/p/2a1b2f17d…

psy-lob-saw.blogspot.com/2014/10/the…

www.cnblogs.com/littleLord/…

我的公衆號

更多文章，請關注公衆號：二進制之路