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

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

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

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

CMS的工作流程

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

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

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

優(yōu)勢(shì)

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

缺陷

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

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

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

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

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

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

內(nèi)存管理策略

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

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

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

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

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

參數(shù)配置

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

新生代搭配

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

替代方案：G1與ZGC

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

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

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