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

1.CMS回收器的核心設(shè)計理念

CMS回收器的核心設(shè)計理念

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

CMS的工作流程

CMS的回收過程分為四個關(guān)鍵階段

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

CMS的核心優(yōu)勢與缺陷

優(yōu)勢

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

缺陷

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

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

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

關(guān)鍵差異點解析

吞吐量與延遲的權(quán)衡

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

內(nèi)存管理策略

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

調(diào)優(yōu)復(fù)雜度

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

3.CMS的調(diào)優(yōu)實踐與替代方案

CMS調(diào)優(yōu)建議

參數(shù)配置

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

新生代搭配

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

替代方案：G1與ZGC

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

4.小結(jié)：如何選擇垃圾回收器

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