CMS GC
Java 中的垃圾收集（Garbage Collection）的基本概念。在 Java 中，當我們創建對象時，這些對象會被存儲在一個名為堆（Heap）的內存區域中。當這些對象不再被使用時，它們就變成了"垃圾"，需要被清理出堆，以釋放空間供新的對象使用。這就是垃圾收集的工作。
CMS GC 是 Java 中的一種垃圾收集器，它的主要目標是減少垃圾收集導致的應用程序停頓時間。它的工作流程大致如下：
- 初始標記（Initial Mark）：這是一個需要停止所有應用程序線程的階段，也就是我們所說的 "Stop-The-World"。在這個階段，GC 會標記出所有從根（Root）開始直接可達的對象。
- 並行標記（Concurrent Mark）：在這個階段，GC 會在應用程序線程運行的同時，標記出所有從根對象開始間接可達的對象。這個階段的名稱 "並行"，就是指 GC 能夠與應用程序線程同時運行。
- 重新標記（Remark）：這也是一個 "Stop-The-World" 階段。因為在並行標記階段，應用程序線程還在修改對象引用，所以可能會有一些新的可達對象被遺漏，或者有一些已經不再可達的對象被錯誤地標記。因此，GC 需要再次停止所有應用程序線程，對這些對象進行重新標記。
- 並行清除（Concurrent Sweep）：在這個階段，GC 會清除掉所有未被標記的對象，也就是不再被應用程序使用的對象。這個階段也是並行進行的，不會影響應用程序的運行。
在 CMS GC 中，一個物件可能會經歷以下的生命週期：
物件創建：當你在 Java 程式中創建一個新的物件，它會被存放在 Heap 中。
物件使用：在物件被創建後，你的程式可能會使用這個物件，這可能包括讀取物件的屬性，調用物件的方法，或者將物件作為參數傳遞給其他方法。
物件變為垃圾：當你的程式不再使用一個物件，並且沒有任何引用指向這個物件時，這個物件就變成了垃圾。這意味著這個物件不再可達，並且可以被垃圾收集器清理。
垃圾收集：在 CMS GC 的運作過程中，這個物件會被標記為垃圾，並在適當的時候被清理。如果物件在並行標記階段被標記，那麼它將在並行清除階段被清理。如果物件在重新標記階段被標記，那麼它將在下一個並行清除階段被清理。
物件清理：當物件被清理時，它佔用的內存空間將被釋放，並可以被用來存放新的物件。在這個過程中，物件的終結器（如果有的話）將被調用。
- 並行標記清除 GC (CMS)
- 這是為了偏好較短的垃圾收集暫停的應用程式而設計的。
- 它適合互動式的應用程式。
- CMS GC 使用多個 GC 線程來掃描 heap。
- 它的大部分工作是與應用程式線程並行進行的。
- Heap 結構
- Heap 被劃分為：Eden, Survivor (S0 和 S1), Old。
- 物件最初在 Eden 中分配。
- 每次 Minor GC 後，活著的物件被移動到一個 Survivor 空間。
- 在 Survivor 空間中生存足夠長時間的物件被移動到 Old generation。
- GC 過程
- Minor GC：清理 Eden 和 Survivor 空間。
- Major GC (也被稱為 Concurrent Mark Sweep GC)：清理 Old generation。
- Major GC 是並行的，這意味著它在應用程式運行的時候發生。
- 如果 Old generation 變滿，將會發生 Full GC，這是一個停止世界的事件。
- 調整
- CMS GC 是可調的，允許你在吞吐量和暫停時間之間取得平衡。
- 重要的選項包括：-XX:ParallelCMSThreads, -XX:CMSInitiatingOccupancyFraction。
不過 CMS GC 執行久了會有記憶體碎片化的問題, 這問題主要來自於它的垃圾收集策略。CMS GC 是一種以減少暫停時間為目標的垃圾收集器，它的主要工作是在應用程式運行的同時進行垃圾收集。為了達到這個目標，CMS GC 在大部分時間內都避免進行記憶體整理。
在 CMS GC 中，當物件被回收時，它們佔用的記憶體空間會被釋放，但並不會立即被重新使用。這些釋放的記憶體空間會形成一個個的"空洞"，這些"空洞"分散在整個堆中，形成了所謂的"碎片"。隨著時間的推移，這些碎片可能會變得越來越多，導致記憶體碎片化。
記憶體碎片化可能會導致一些問題。例如，當應用程式需要分配一個大物件時，可能會找不到足夠大的連續記憶體空間，即使整體的可用記憶體空間是足夠的。在這種情況下，CMS GC 可能需要進行一次完全的垃圾收集和記憶體整理，這會導致一次長時間的暫停。
雖然 CMS GC 會把物件在 S0 和 S1（Survivor 0 和 Survivor 1）搬移，但它們是用於物件年齡管理和晉升的。在 Minor GC 中，活著的物件會在 Eden、S0 和 S1 之間移動，並最終被晉升到 Old Generation。這個過程確實會進行一些記憶體整理，但這只影響到 Young Generation，並不能解決 Old Generation 的記憶體碎片化問題。
STW - Stop the world
"Stop the World" 是 Java 垃圾收集中的一個術語。當垃圾收集器需要進行某些工作時，它會要求所有的應用程式線程（也就是你的 Java 程式正在執行的線程）暫時停止執行，這就是所謂的 "Stop the World"。
你可以將其想像成在公路上的交通管制。當有重要的車輛（例如警車或救護車）需要通過時，所有其他的車輛都必須停下來，讓重要的車輛先行。在這個比喻中，重要的車輛就像垃圾收集器，而其他的車輛就像應用程式的線程。
"Stop the World" 的時間通常會盡量短，以減少對應用程式的影響。但是，如果垃圾收集器需要清理大量的垃圾，或者需要進行大規模的內存整理，那麼 "Stop the World" 的時間可能會比較長。這就是為什麼在設計和選擇垃圾收集器時，我們需要考慮到 "Stop the World" 的影響。
在 CMS (Concurrent Mark Sweep) GC 中，Eden Space 的 Minor GC 是 Stop-The-World (STW) 的主要原因是為了簡化設計和提高效率。
- 簡化設計：Minor GC 是一個複雜的過程，它需要確定哪些物件是活著的，哪些物件是死的，並且需要更新所有活著的物件的引用。如果在這個過程中允許應用程式並行運行，那麼就需要處理應用程式可能會改變物件狀態和引用的複雜情況。這會使得 GC 的設計和實現變得更加複雜。因此，為了簡化設計，選擇在 Minor GC 時暫停應用程式。
- 提高效率：Minor GC 通常只處理 Eden Space，這是一個相對較小的區域，並且由於 Java 的物件分配模型，大部分物件在 Eden Space 中不會存活很長時間。因此，Minor GC 通常可以很快完成。如果在這個過程中允許應用程式並行運行，那麼就需要付出額外的同步和協調的代價，這可能會降低 GC 的效率。
因此，儘管 STW 會導致應用程式的暫停，但在 Eden Space 的 Minor GC 中使用 STW 是一種權衡和妥協的結果。
而 CMS (Concurrent Mark Sweep) GC 的 Remark Phase 是 Stop-The-World (STW) 的原因主要是為了確保堆中所有的物件都被正確地標記。
在 CMS GC 的 Concurrent Marking Phase（並行標記階段）中，GC 會在應用程式運行的同時標記堆中的物件。然而，由於應用程式在運行，所以可能會有新的物件被創建，或者已經存在的物件的引用關係被改變。這些變化可能會導致一些物件的標記狀態變得不正確。
為了解決這個問題，CMS GC 在 Concurrent Marking Phase 之後會進行 Remark Phase（重新標記階段）。在這個階段中，GC 會暫停應用程式，並重新掃描堆中的物件，確保所有的物件都被正確地標記。這就是為什麼 Remark Phase 是 STW 的。
雖然 Remark Phase 是 STW 的，但是由於它只需要處理在 Concurrent Marking Phase 中變化的部分，所以通常可以很快完成。這樣，CMS GC 可以在保證正確性的同時，盡可能地減少 STW 的時間。
G1GC
CMS (Concurrent Mark Sweep) GC 和 G1 (Garbage-First) GC 都是針對減少垃圾收集暫停時間的垃圾收集器。然而，它們在設計和實現上有一些重要的區別，這些區別可能會影響到你選擇哪一種垃圾收集器。以下是一些可能需要從 CMS GC 轉換到 G1 GC 的情況：
- 大堆需求：如果你的應用程式需要一個非常大的堆（例如，數十GB或更大），那麼 G1 GC 可能是一個更好的選擇。G1 GC 的設計目標是支持大堆，並且能夠預測垃圾收集的暫停時間。相比之下，CMS GC 的暫停時間可能會隨著堆的大小增加而增加。
- 預測性暫停時間：如果你需要更好的控制垃圾收集的暫停時間，那麼 G1 GC 可能是一個更好的選擇。G1 GC 提供了一個暫停時間目標，你可以設定這個目標，讓 G1 GC 儘可能地達到這個目標。
- 更高的吞吐量：雖然 CMS GC 在減少暫停時間方面表現出色，但是它可能會導致吞吐量下降，因為它需要在垃圾收集和應用程式之間進行更多的上下文切換。相比之下，G1 GC 通常可以提供更高的吞吐量。
- 更好的記憶體整理：CMS GC 可能會導致記憶體碎片化，特別是在長時間運行的應用程式中。當記憶體碎片化變得嚴重時，CMS GC 可能會導致不可預測的長暫停時間。相比之下，G1 GC 透過定期的整理操作，可以更好地處理記憶體碎片化問題。
G1GC（Garbage-First Garbage Collector）是Java的一種垃圾收集器，它是為了滿足大數據量和低延遲需求而設計的。
以下是G1GC的主要特點和工作原理：
分區收集：G1GC將Java堆分成多個相同大小的區域（Region），每個區域可能是Eden區、Survivor區或Old區。這種分區方式使得G1GC能夠獨立並且並行地收集每個區域，從而減少了單次垃圾收集的停頓時間。
Garbage-First：G1GC的名稱中的"Garbage-First"意味著它優先收集垃圾最多的區域。這種策略使得G1GC能夠最大限度地釋放空間，並且在有限的時間內達到最好的垃圾收集效果。
可預測的停頓時間：G1GC允許你指定最大的垃圾收集停頓時間，它會儘可能地在這個時間限制內完成垃圾收集。這種特性使得G1GC非常適合需要低延遲的應用。
並行和並行階段：G1GC在執行垃圾收集時，有一些階段可以與應用程序線程並行運行，這可以減少垃圾收集對應用程序的影響。
記憶體壓縮：G1GC有一個稱為"記憶體壓縮"的階段，它會在背景中將活躍對象從一個區域移動到另一個區域，從而釋放更多的空間。
全面垃圾收集：當Java堆中的空間不足，或者垃圾收集無法在指定的停頓時間內完成時，G1GC會執行一次全面的垃圾收集（Full GC）。全面垃圾收集會停止所有的應用程序線程，並且收集整個Java堆中的垃圾。
- G1 GC
- G1 GC 的設計目標是降低停頓時間並適應大記憶體。
- 它適合需要大記憶體和短停頓時間的應用程式。
- Heap 結構
- Heap 被分成多個 Region。
- 每個 Region 可以是 Eden, Survivor 或 Old。
- GC 過程
- Minor GC：清理 Eden 和 Survivor。
- Major GC：清理 Old。
- Major GC 進行並行標記和清除。
- 如果需要，會有停頓世界的事件。
- 調整
- G1 GC 是可調的。
- 重要選項包括：-XX:MaxGCPauseMillis, -XX:G1NewSizePercent, -XX:G1MaxNewSizePercent, -XX:G1HeapRegionSize。
Shenandoah GC
Shenandoah GC 是一種低暫停時間的垃圾收集器，它透過與 Java 程式並行執行更多的垃圾收集工作來減少 GC 暫停時間。Shenandoah 的大部分 GC 工作都是並行進行的，包括並行壓縮，這意味著它的暫停時間不再直接與堆大小成比例。無論是對 200 GB 的堆進行垃圾收集，還是對 2 GB 的堆進行垃圾收集，都應該具有相似的低暫停行為。
在 Shenandoah GC 中，一個物件的生命週期會經歷以下階段：
- 初始化標記 (Init Mark)：這個階段會開始並行標記，準備堆和應用程式線程進行並行標記，然後掃描根集。這是循環中的第一個暫停，最主要的時間消耗者是根集掃描。因此，其持續時間取決於根集的大小。
- 並行標記 (Concurrent Marking)：這個階段會遍歷堆，並追蹤可達物件。這個階段與應用程式並行運行，其持續時間取決於活動物件的數量和堆中物件圖的結構。由於應用程式在此階段可以分配新數據，因此在並行標記期間，堆佔用率會上升。
- 最終標記 (Final Mark)：這個階段會完成並行標記，通過排空所有待處理的標記/更新隊列並重新掃描根集。它還通過找出要撤離的區域（收集集），預撤離一些根，並一般準備運行時進入下一階段。這是循環中的第二個暫停，這裡的最主要時間消耗者是排空隊列和掃描根集。
- 並行清理 (Concurrent Cleanup)：這個階段會回收立即垃圾區域，也就是在並行標記後檢測到沒有活動物件存在的區域。
- 並行撤離 (Concurrent Evacuation)：這個階段會從收集集中的活動物件撤離到新區域。這個階段與應用程式並行運行，其持續時間取決於收集集中的活動物件數量。
- 初始化更新引用 (Init Update Refs)：這個階段會準備堆和應用程式線程進行並行更新引用，然後掃描根集。這是循環中的第三個暫停，最主要的時間消耗者是根集掃描。
- 並行更新引用 (Concurrent Update Refs)：這個階段會遍歷堆，並更新物件引用以指向撤離物件的新位置。這個階段與應用程式並行運行，其持續時間取決於堆中的物件數量。
- 最終更新引用 (Final Update Refs)：這個階段會完成並行更新引用，通過排空所有待處理的更新隊列並重新掃描根集。這是循環中的第四個暫停，最主要的時間消耗者是排空隊列和掃描根集。
- 並行清理 (Concurrent Cleanup)：這個階段會回收所有剩餘的垃圾區域，也就是在並行更新引用後檢測到沒有活動物件存在的區域。
這就是 Shenandoah GC 中一個物件的生命週期。在這個過程中，物件會被標記、撤離、更新引用，並最終被清理。這個過程的大部分階段都與應用程式並行運行，從而實現低暫停時間的垃圾收集。
在垃圾收集過程中，特別是在物件撤離（Evacuation）階段，物件可能會被移動到堆的其他位置。如果在物件被移動的同時，應用程式試圖讀取該物件的引用，那麼它可能會讀取到一個無效的引用，因為該物件已經不再位於原來的位置。
為了解決這個問題，Shenandoah GC 在應用程式讀取物件引用時插入了一個 "Read Barrier"。這個 "Read Barrier" 會檢查該物件是否正在被撤離。如果是，那麼 "Read Barrier" 會先等待撤離完成，然後返回物件新的位置。這樣，應用程式就可以正確地讀取物件的引用，即使該物件正在被移動。
"Read Barrier" 是一種低開銷的操作，因為它只需要檢查物件的撤離狀態，並且只有在物件正在被撤離時才需要等待。因此，它不會對應用程式的性能產生顯著影響。
Shenandoah GC 也有一些階段會產生 Stop-The-World (STW) 暫停，但這些暫停的時間通常非常短，並且與堆的大小無關。這是因為 Shenandoah GC 的設計目標是使大部分的垃圾收集工作都能與應用程式並行進行。
在 Shenandoah GC 中，以下四個階段會產生 STW 暫停：
初始化標記 (Init Mark)：這個階段會開始並行標記，準備堆和應用程式線程進行並行標記，然後掃描根集。
最終標記 (Final Mark)：這個階段會完成並行標記，通過排空所有待處理的標記/更新隊列並重新掃描根集。
初始化更新引用 (Init Update Refs)：這個階段會準備堆和應用程式線程進行並行更新引用，然後掃描根集。
最終更新引用 (Final Update Refs)：這個階段會完成並行更新引用，通過排空所有待處理的更新隊列並重新掃描根集。
這些 STW 暫停的時間主要取決於根集的大小，而不是整個堆的大小。根集是指那些可能引用堆中其他物件的物件，通常包括全局變數、執行緒堆疊等。根集的大小通常遠小於整個堆的大小，因此這些 STW 暫停的時間通常非常短。
至於 "更新引用" 的階段，這個階段是與應用程式並行進行的。在這個階段中，Shenandoah GC 會遍歷堆，並更新物件引用以指向撤離物件的新位置。由於這個階段是與應用程式並行進行的，所以它不會產生 STW 暫停，並且其持續時間與堆的大小無關。
G1 (Garbage-First) GC 和 Shenandoah GC 都是針對減少垃圾收集暫停時間的垃圾收集器，但它們在設計和實現上有一些重要的區別。以下是一些可能需要從 G1 GC 轉換到 Shenandoah GC 的情況：
- 更低的暫停時間：如果你的應用程式對垃圾收集的暫停時間有非常嚴格的要求，那麼 Shenandoah GC 可能是一個更好的選擇。Shenandoah GC 的設計目標是提供更低的暫停時間，它的大部分工作都是與應用程式並行進行的，包括壓縮（Compaction）。
- 大堆需求：如果你的應用程式需要一個非常大的堆（例如，數十GB或更大），那麼 Shenandoah GC 可能是一個更好的選擇。Shenandoah GC 的暫停時間與堆的大小無關，這使得它更適合於大堆的情況。
- 更好的記憶體整理：如果你的應用程式有大量的長生命周期物件，或者有大量的大物件，那麼可能會遇到記憶體碎片化的問題。在這種情況下，Shenandoah GC 可能是一個更好的選擇，因為它可以在應用程式運行的同時進行記憶體整理。
在應用程式使用非常大的記憶體時
G1 GC 確實可以處理大型堆（例如數十GB或更大），並且它的設計目標就是為了更好地處理大型堆。然而，與 Shenandoah GC 相比，G1 GC 在處理大型堆時可能會有一些限制。
G1 GC 的暫停時間通常與堆的大小有關。這是因為 G1 GC 在執行全局垃圾收集（也稱為"Stop-The-World"收集）時，需要遍歷整個堆。因此，堆越大，全局垃圾收集所需的時間就越長。
另一方面，Shenandoah GC 的設計目標是使暫停時間與堆的大小無關。這是因為 Shenandoah GC 的大部分工作（包括標記和整理）都是與應用程式並行進行的。因此，即使堆非常大，Shenandoah GC 的暫停時間也可以保持在一個較低的水平。
因此，如果你的應用程式需要一個非常大的堆，並且你希望垃圾收集的暫停時間盡可能地低，那麼 Shenandoah GC 可能是一個更好的選擇。然而，這並不意味著 G1 GC 不能處理大型堆，只是在某些情況下，Shenandoah GC 可能會表現得更好。
