在JVM的垃圾回收（GC）機制中，停頓時間（STW）和吞吐量（Throughput）是兩個核心指標。不同的垃圾回收器在這兩者間各有側重，而CMS（Concurrent Mark-Sweep）和并行回收器（Parallel GC）正是兩種典型的設計思路。

1.CMS回收器的核心設計理念

CMS回收器的核心設計理念

CMS（Concurrent Mark-Sweep）是Java中以低停頓時間為核心目標的老年代垃圾回收器，尤其適用于對響應延遲敏感的應用（如在線服務、實時交易系統）。它的設計理念是盡可能減少用戶線程的停頓，通過并發標記與清理實現“用戶線程與GC線程交替工作”的效果。

CMS的工作流程

CMS的回收過程分為四個關鍵階段

• 初始標記（Initial Mark）：標記與GC Roots直接關聯的對象，需暫停用戶線程（STW），但時間極短。
• 并發標記（Concurrent Mark）：多線程并發遍歷對象圖，標記存活對象，與用戶線程并行執行（此時應用可能產生新垃圾）。
• 重新標記（Remark）：修正并發標記階段因用戶線程修改引用導致的“臟標記”，需短暫STW。
• 并發清除（Concurrent Sweep）：清理未被標記的垃圾對象，無需暫停用戶線程，但會產生內存碎片。

CMS的核心優勢與缺陷

優勢

• 低延遲：大部分階段無需暫停用戶線程，平均停頓時間可控制在毫秒級。
• 高并發性：利用多核CPU資源，減少GC對應用性能的影響。

缺陷

• 內存碎片：標記-清除算法導致內存不連續，可能觸發Full GC（使用Serial Old回收器整理內存，停頓時間陡增）。
• CPU資源競爭：并發階段占用CPU，可能降低應用吞吐量。
• 浮動垃圾處理：無法回收并發階段新產生的垃圾，需預留內存空間（默認老年代68%觸發回收）。

2.CMS與并行回收器的核心差異

并行回收器（如Parallel Scavenge/Old）以最大化吞吐量為目標，適用于后臺計算密集型任務（如批處理、數據分析）。兩者的差異體現在多個維度

關鍵差異點解析

吞吐量與延遲的權衡

• 并行回收器通過多線程集中回收垃圾，縮短GC總耗時，但單次STW時間可能較長（如老年代回收）。
• CMS通過分階段并發，犧牲部分吞吐量以換取更平滑的響應曲線。

內存管理策略

• CMS的標記-清除算法需配置碎片整理參數（-XX:+UseCMSCompactAtFullCollection），否則可能因碎片觸發Full GC。
• 并行回收器的標記-整理算法天然規避碎片問題，適合長期運行的大內存應用。

調優復雜度

• CMS需精細控制觸發閾值（-XX:CMSInitiatingOccupancyFraction）和碎片整理頻率，否則易引發性能波動。
• 并行回收器支持自適應策略（-XX:+UseAdaptiveSizePolicy），JVM自動優化堆分區比例。

3.CMS的調優實踐與替代方案

CMS調優建議

參數配置

• 設置合理的老年代觸發閾值（建議70%~80%），避免內存增長過快導致并發失敗。
• 啟用碎片整理（-XX:+UseCMSCompactAtFullCollection）并限制整理頻率（-XX:CMSFullGCsBeforeCompactinotallow=5）。

新生代搭配

使用ParNew回收器（多線程版Serial）與CMS配合，避免新生代GC成為瓶頸。

替代方案：G1與ZGC

• G1回收器：分區化內存管理，兼顧吞吐量與低延遲，通過預測模型（Mixed GC）避免全局停頓，適合大堆內存（>6GB）。
• ZGC回收器：TB級堆內存下停頓時間<10ms，采用染色指針和讀屏障技術，徹底解決碎片問題，但需JDK11+。

4.小結：如何選擇垃圾回收器

• CMS適用場景：中小規模堆內存（<6GB）、對延遲敏感、允許偶爾的Full GC停頓（如電商交易系統）。
• 并行回收器適用場景：計算密集型任務、可接受較長STW以換取更高吞吐量（如日志分析）。
• 未來趨勢：G1和ZGC逐步取代CMS，尤其在JDK8+環境中，G1已成為默認回收器。