JVM CMS垃圾收集器 系统性知识体系总结

谈到JVM的垃圾回收机制，有一个经典组件无法绕过：CMS。作为HotSpot虚拟机在JDK 1.5时期引入的并发低延迟收集器，它堪称JVM历史上首个真正实现垃圾回收线程与用户线程并发执行的关键角色。

设计初衷极为明确：追求最短的回收停顿时间，优先保障系统响应速度。其适用场景大家也颇为熟悉，即互联网Web应用、B/S架构系统、桌面GUI等对用户体验敏感的交互环境。值得留意的是，CMS仅作用于老年代，必须搭配年轻代的Serial或ParNew收集器协同工作。核心算法采用的是并发版本的标记-清除机制。

二、CMS核心原理

2.1 并发执行的本质

CMS的精妙之处在于，它将最耗时的标记和清除阶段与用户线程并发执行，从而将单次STW时间大幅缩短。当然，它也借助多线程并行处理垃圾回收任务，充分挖掘多核CPU的计算潜力。

2.2 三色标记法（并发标记的基础）

为了实现高效的并发标记，CMS引入了三色标记法。该方法将对象划分为三类：

• 白色：尚未被收集器访问过的对象，此为初始状态，最终将被回收处理。
• 灰色：已经被访问过，但至少还有一个引用尚未完成扫描。
• 黑色：已经被访问过，并且所有引用均已扫描完毕，属于存活对象。

这里面存在一个核心难题：用户线程在标记过程中可能随时修改引用关系，导致原本存活的对象被错误地标记为白色，此即对象丢失问题。

2.3 增量更新（Incremental Update）解决方案

CMS应对这一问题的策略是“增量更新”算法。简单来说，当某个黑色对象新增加了一个指向白色对象的引用时，该黑色对象会被重新标记为灰色。随后在最终的重新标记阶段，系统会再次扫描所有灰色对象，确保所有存活对象都能被正确标记。其原理在于打破了“黑色对象不会引用白色对象”这一导致对象丢失的前提条件，从而保障标记的准确性。

三、CMS完整回收流程（7个阶段）

CMS的回收过程共分为7个阶段，其中4个为STW阶段，3个为并发阶段。按执行顺序来看：

阶段1：初始标记（Initial Mark）- STW

• 耗时：极短，通常为毫秒级。
• 任务：仅标记与GC Roots直接关联的对象。
• 特点：JDK 1.6之后改为多线程执行，停顿时间与堆大小无关，仅受GC Roots数量影响。

阶段2：并发标记（Concurrent Mark）- 并发

• 耗时：最长，与堆中存活对象数量成正比。
• 任务：从初始标记的对象出发，遍历整个对象图，标记所有存活对象。
• 特点：与用户线程完全并发执行，不产生停顿。但由于用户线程可能修改引用，标记结果可能不精确。

阶段3：并发预清理（Concurrent Preclean）- 并发

• 耗时：较短。
• 任务：处理并发标记阶段产生的脏卡，标记从年轻代晋升至老年代的对象，提前处理部分引用变更，减轻后续重新标记阶段的工作负担。
• 特点：可通过参数控制执行时长，目的就是为了缩短最终重新标记的STW停顿时间。

阶段4：并发可中断预清理（Concurrent Abortable Preclean）- 并发

• 耗时：可配置，默认最长5秒。
• 任务：与并发预清理类似，但支持被中断。
• 特点：主要目的是等待年轻代发生Minor GC。因为年轻代GC之后，老年代的引用关系会相对稳定，从而进一步减少重新标记的工作量。

阶段5：最终标记（Final Remark）- STW

• 耗时：中等，比初始标记长，但远短于并发标记。
• 任务：修正并发标记阶段因用户线程修改引用而产生的标记错误；重新扫描所有GC Roots；处理增量更新记录的引用变化。
• 特点：多线程并行执行，是CMS整个回收过程中第二长的停顿阶段。

阶段6：并发清除（Concurrent Sweep）- 并发

• 耗时：较长，与垃圾数量成正比。
• 任务：清除所有被标记为垃圾的对象，释放内存空间。
• 特点：与用户线程并发执行，不移动存活对象，直接回收垃圾内存。

阶段7：并发重置（Concurrent Reset）- 并发

• 耗时：极短。
• 任务：重置CMS收集器的内部数据结构，为下一次垃圾回收做好准备。
• 特点：与用户线程并发执行，不影响应用性能。

四、CMS核心优缺点分析

4.1 显著优点

• 低延迟：超过90%的工作在并发阶段完成，STW时间通常控制在几十毫秒以内。
• 高并发：充分利用多核CPU资源，垃圾回收与应用程序同步运行。
• 响应迅速：特别适合对用户体验要求高的交互式应用。
• 成熟稳定：历经多年生产环境验证，积累了丰富的调优经验。

4.2 致命缺点

CPU资源消耗大

• 并发阶段会占用较多CPU线程，默认占用CPU核心数的1/4。
• 在CPU核心数较少的服务器上（例如2核），会严重影响应用的吞吐量。
• 当CPU负载较高时，并发回收的效率会急剧下降。

内存碎片问题

• 基于标记-清除算法，回收后会产生大量不连续的内存碎片。
• 碎片积累过多，大对象可能无法分配，从而提前触发Full GC。
• 虽然有-XX:UseCMSCompactAtFullCollection参数用于压缩整理，但压缩阶段会产生较长的STW停顿。

并发模式失败（Concurrent Mode Failure）

• 在并发清除阶段，用户线程仍在运行，会持续产生新的垃圾（亦称“浮动垃圾”）。
• 如果老年代剩余空间不足以容纳这些浮动垃圾，就会触发并发模式失败。
• 此时CMS会退化为Serial Old收集器，以单线程方式执行Full GC，导致极长的STW停顿，可能长达数秒甚至数十秒。

无法处理浮动垃圾

• 并发标记和清除阶段产生的新垃圾，只能等待下一次GC才能回收。
• 因此CMS需要预留一部分内存空间给浮动垃圾，默认老年代使用率达到68%时即触发GC。
• 预留空间过小会引发并发模式失败，预留过大又会浪费内存资源。

五、CMS被废弃的根本原因

CMS在JDK 9中被标记为废弃，并在JDK 14中被彻底移除。主要原因有以下几点：

5.1 设计缺陷无法根本解决

• 内存碎片问题：这是标记-清除算法固有的缺陷，无论怎样调优都无法彻底根除。
• 并发模式失败风险：始终存在退化为Serial Old的可能性，这无疑是生产环境的重大隐患。
• CPU资源占用：在低配置服务器上表现不佳，难以适配现代多核CPU的发展趋势。

5.2 G1收集器的全面超越

G1收集器在JDK 7中正式推出，并在JDK 9中成为默认收集器，全面取代了CMS：

• 统一收集年轻代和老年代：无需再配合其他收集器使用，简化了JVM配置过程。
• 基于Region的内存布局：将堆划分为多个大小相等的Region，有效解决了内存碎片问题。
• 可预测的停顿时间模型：用户可以指定最大停顿时间，G1会尽力满足该目标。
• 并行与并发结合：既充分利用多核CPU，又保持低延迟特性。
• 整体标记-整理，局部复制：兼顾了吞吐量和内存利用率。

5.3 维护成本过高

• CMS的代码极为复杂，维护难度相当大。
• 随着JVM的演进，CMS与其他新特性（如ZGC、Shenandoah）的兼容性越来越差。
• Oracle已将开发资源集中在更先进的G1、ZGC和Shenandoah收集器上。

六、补充知识：CMS关键参数调优

七、总结

从历史视角来看，CMS是JVM垃圾回收技术发展史上的一个重要里程碑。它首次实现了并发垃圾回收，攻克了传统收集器停顿时间过长的难题，为互联网应用的蓬勃发展做出了巨大贡献。

当然，随着技术的持续演进，它基于标记-清除算法的固有缺陷，以及G1等新一代收集器的崛起，最终被淘汰也是必然趋势。不过，它的设计思想——例如并发标记、增量更新——对后续收集器的发展产生了深远影响，至今仍是学习JVM垃圾回收机制不可或缺的重要内容。

CMS垃圾收集器 面试问答卡片（可直接背诵）

一、基础概念类

Q1：什么是CMS垃圾收集器？它的设计目标和适用场景是什么？

A：
CMS全称为Concurrent Mark Sweep（并发标记清除），是HotSpot在JDK1.5推出的第一个真正意义上的并发低延迟收集器。
设计目标是追求最短的STW停顿时间，优先保证响应速度。
适用场景包括互联网Web应用、B/S系统、桌面GUI等对用户体验敏感的系统。
它只作用于老年代，必须配合年轻代的Serial或ParNew收集器使用。
核心算法是并发版本的标记-清除算法。

Q2：CMS和传统收集器（如Serial Old）最本质的区别是什么？

A：
传统收集器（Serial Old、Parallel Old）在垃圾回收时全程STW，停顿时间与堆大小成正比；而CMS将超过90%的耗时工作（标记、清除）与用户线程并发执行，仅在几个关键阶段短暂停顿，从而大幅降低单次停顿时间。

二、核心原理类

Q3：CMS使用什么算法实现并发标记？它将对象分为哪几类？

A：
CMS采用三色标记法实现并发标记，将对象分为三类：

• 白色：尚未被收集器访问过，最终将被回收。
• 灰色：已经被访问过，但至少有一个引用尚未扫描完。
• 黑色：已经被访问过，并且所有引用均已扫描完毕，属于存活对象。

Q4：并发标记阶段会产生什么核心问题？CMS是如何解决的？

A：
核心问题是对象丢失，即用户线程在标记过程中修改了引用关系，导致原本存活的对象被误标为白色。
解决方案是增量更新算法：当一个黑色对象新增了对白色对象的引用时，就将该黑色对象重新标记为灰色；然后在最终重新标记阶段，重新扫描所有灰色对象，确保所有存活对象都被正确标记。
其原理是打破了“黑色对象不会引用白色对象”这一导致对象丢失的必要条件。

三、回收流程类

Q5：CMS完整的回收流程分为哪7个阶段？哪些是STW阶段？

A：
CMS回收流程按顺序分为7个阶段，其中4个STW阶段，3个并发阶段：

• ✅ 初始标记（STW，极短）
• ⚡ 并发标记（并发，最长）
• ⚡ 并发预清理（并发，较短）
• ⚡ 并发可中断预清理（并发，可配置）
• ✅ 最终标记（STW，中等）
• ⚡ 并发清除（并发，较长）
• ⚡ 并发重置（并发，极短）

Q6：请简述CMS每个核心阶段的主要任务和特点

A：

• 初始标记：仅标记GC Roots直接关联的对象；多线程执行，停顿时间与堆大小无关，只取决于GC Roots数量。
• 并发标记：从初始标记对象出发遍历整个对象图；与用户线程完全并发，标记结果可能不精确。
• 并发预清理：处理并发标记产生的脏卡，标记从年轻代晋升的对象；目的是减轻最终标记的负担。
• 并发可中断预清理：与预清理类似，但可中断；等待年轻代Minor GC以进一步减少重新标记的工作量。
• 最终标记：修正并发标记阶段的标记错误，重新扫描GC Roots和增量更新记录；是CMS第二长的停顿阶段。
• 并发清除：清除所有标记为垃圾的对象；不移动存活对象，直接回收内存。
• 并发重置：重置内部数据结构，为下一次GC做准备。

四、优缺点类

Q7：CMS有哪些显著的优点？

A：

• 低延迟：绝大多数工作并发执行，STW时间通常控制在几十毫秒以内。
• 高并发：充分利用多核CPU资源，垃圾回收与应用同步运行。
• 响应迅速：特别适合交互式应用，有效提升用户体验。
• 成熟稳定：经过多年生产环境验证，调优经验丰富。

Q8：CMS有哪些致命的缺点？（高频考点）

A：

• CPU资源消耗大：并发阶段默认占用1/4的CPU核心数，低配置服务器上会严重影响吞吐量。
• 内存碎片问题：基于标记-清除算法，回收后产生大量不连续碎片，导致大对象无法分配，提前触发Full GC。
• 并发模式失败风险：并发清除阶段产生的浮动垃圾若超出预留内存，CMS会退化为Serial Old单线程收集器，产生极长STW停顿。
• 无法处理浮动垃圾：并发阶段产生的新垃圾只能等到下一次GC回收，因此需要预留部分内存，造成资源浪费。

Q9：什么是CMS的"并发模式失败"？它会导致什么后果？

A：
定义是：在并发清除阶段，用户线程仍在运行并产生新的垃圾（浮动垃圾），如果老年代剩余空间不足以容纳这些浮动垃圾，就会触发并发模式失败。
后果是：CMS会立即停止所有并发回收线程，退化为Serial Old单线程收集器，对整个老年代进行Full GC，此时会产生极长的STW停顿，是生产环境的重大隐患。

五、废弃原因类

Q10：CMS为什么会被废弃？它在哪个JDK版本被标记为废弃，哪个版本被完全移除？

A：
版本方面：在JDK 9中被标记为废弃，JDK 14中被完全移除。
根本原因有三个：固有设计缺陷无法解决，例如标记-清除算法导致的内存碎片、并发模式失败风险、CPU占用高等问题；G1收集器的全面超越，G1统一收集年轻代和老年代，基于Region布局解决了碎片问题，支持可预测的停顿时间模型，兼顾了吞吐量和延迟；维护成本过高，CMS代码复杂，与JVM新特性兼容性差，Oracle将开发资源转向了G1、ZGC和Shenandoah等新一代收集器。

六、调优参数类

Q11：列举5个CMS最常用的调优参数及其作用

A：

• -XX:+UseConcMarkSweepGC：启用CMS收集器
• -XX:CMSInitiatingOccupancyFraction=75：老年代使用率达到75%时触发CMS GC（默认68%）
• -XX:+UseCMSCompactAtFullCollection：Full GC时进行内存压缩（JDK8默认开启）
• -XX:CMSFullGCsBeforeCompaction=5：每5次Full GC后进行一次压缩（默认0，每次都压缩）
• -XX:ConcGCThreads=4：设置并发阶段的GC线程数（默认是ParallelGCThreads/4）

CMS vs G1 垃圾收集器 对比面试问答卡片（高频考点）

一、基础定位与核心差异类

Q1：CMS和G1最根本的区别是什么？

A：
首先，内存布局不同。CMS采用传统分代式内存布局，年轻代和老年代是连续空间；G1采用Region化内存布局，将整个堆划分为多个大小相等的独立Region（1MB~32MB），每个Region可动态扮演Eden、Survivor或老年代。
其次，设计目标不同。CMS唯一目标是最短停顿时间，牺牲了部分吞吐量；G1的目标是在可预测的停顿时间内实现高吞吐量，兼顾两者。
最后，作用范围不同。CMS仅收集老年代，必须配合年轻代的ParNew/Serial收集器；G1同时收集年轻代和老年代，属于全堆收集器。

Q2：CMS和G1分别在哪个JDK版本成为默认收集器？

A：
CMS从未成为过默认收集器，JDK 8及以前服务器模式默认的是Parallel Sca venge + Parallel Old。
G1在JDK 9及以后成为默认垃圾收集器，同时CMS在JDK 9被标记为废弃，JDK 14被完全移除。

二、核心原理对比类

Q3：CMS和G1使用的核心垃圾回收算法有什么不同？

A：
CMS基于标记-清除算法，优点是并发执行、停顿时间短，缺点是产生大量内存碎片。
G1采用“整体标记-整理，局部复制”的混合算法。从全局看，基于标记-整理算法，不会产生内存碎片；从局部看，回收Region时采用复制算法，将存活对象复制到其他空Region。优点在于彻底解决了内存碎片问题，大对象分配更顺畅。

Q4：CMS和G1解决并发标记对象丢失问题的方案有什么不同？

A：
CMS采用增量更新算法，关注的是引用的新增。当黑色对象新增对白色对象的引用时，就将该黑色对象重新标记为灰色，然后在最终标记阶段重新扫描所有灰色对象。
G1采用原始快照算法，关注的是引用的删除。当某个对象的引用被删除时，就记录下该引用的原始快照，然后在最终标记阶段扫描这些快照，确保被删除引用指向的对象不会被误回收。
从性能上看，原始快照比增量更新效率更高，因为它不需要在重新标记阶段重新扫描整个对象图。

三、回收流程对比类

Q5：CMS和G1的回收流程有什么本质区别？

A：

Q6：什么是G1的Mixed GC？它和CMS的老年代GC有什么不同？

A：
Mixed GC是G1特有的回收模式。当老年代占用率达到阈值（默认45%）时触发，同时回收所有年轻代Region和部分老年代Region。
与CMS老年代GC的区别在于：CMS每次回收整个老年代，停顿时间不可控；G1每次只回收部分老年代Region，停顿时间可预测。CMS回收后会产生内存碎片；G1回收时采用复制算法，不会产生碎片。CMS只能在老年代满了之后触发；G1可根据停顿时间目标灵活调整回收的Region数量。

四、性能与问题对比类

Q7：CMS和G1在停顿时间方面有什么差异？

A：
CMS的停顿时间不可预测。正常情况下停顿时间很短，几十毫秒；但一旦发生并发模式失败，就会退化为Serial Old单线程Full GC，停顿时间可能长达数秒甚至数十秒。
G1的停顿时间可预测。用户可以通过-XX:MaxGCPauseMillis参数指定最大停顿时间，默认200ms。G1会根据历史回收数据，计算每个Region的回收耗时，选择合适数量的Region进行回收，尽量满足停顿时间目标。即使发生Full GC，JDK 10及以后的G1也支持并行Full GC，停顿时间比CMS的Serial Old短得多。

Q8：CMS的"并发模式失败"和G1的"疏散失败"有什么区别？

A：
CMS并发模式失败的原因是，并发清除阶段产生的浮动垃圾超出了老年代预留空间。后果是退化为Serial Old单线程收集器，全堆Full GC，产生极长STW停顿。
G1疏散失败的原因是，回收Region时没有足够的空Region来存放存活对象。后果是触发Full GC，JDK 10前是单线程，JDK 10及以后是多线程并行。总体来看，G1的疏散失败比CMS的并发模式失败后果轻得多，也更容易通过调优避免。

Q9：CMS和G1在处理大对象方面有什么不同？

A：
CMS中，大对象直接分配到老年代。问题在于容易触发提前Full GC，而且内存碎片会导致大对象分配失败。
G1专门设计了Humongous Region（大对象区）。大小超过Region一半的对象被视为大对象，直接分配在连续的Humongous Region中。优点是，大对象不会进入年轻代，避免了频繁复制；回收时可以单独回收Humongous Region，效率更高。

五、适用场景与调优对比类

Q10：CMS和G1分别适用于什么场景？

A：
CMS适用场景（已不推荐新项目使用）：JDK 8及以下版本，堆内存较小（<8GB），对响应时间要求极高且能接受偶尔的长时间停顿，CPU资源充足（4核及以上）。
G1适用场景（推荐所有新项目使用）：JDK 9及以上版本，堆内存较大（8GB~64GB），需要兼顾吞吐量和响应时间，希望有可预测的停顿时间，大对象较多的应用。

Q11：CMS和G1最核心的调优参数分别是什么？

A：
CMS核心调优参数包括：-XX:CMSInitiatingOccupancyFraction设置老年代触发GC的阈值；-XX:+UseCMSCompactAtFullCollection控制Full GC时进行内存压缩；-XX:ConcGCThreads设置并发GC线程数。
G1核心调优参数包括：-XX:MaxGCPauseMillis设置最大停顿时间目标，这是最重要的参数；-XX:G1HeapRegionSize设置每个Region的大小（1MB~32MB，必须是2的幂）；-XX:InitiatingHeapOccupancyPercent设置触发并发标记的堆占用阈值，默认45%。

六、总结对比表（面试速记）