CMS 垃圾收集器：详解初始标记、并发标记、重新标记、并发清除四个阶段中哪些需要 Stop The World

CMS垃圾收集器：详解初始标记、并发标记、重新标记、并发清除四个阶段中哪些需要 Stop The World

说到CMS垃圾收集器，一个绕不开的核心话题就是：它到底在哪些环节会“暂停世界”？答案是明确的：在它的四个标准工作阶段里，只有初始标记和重新标记这两个阶段需要触发Stop The World（STW）。这种设计，正是CMS以“低延迟”为核心目标的直接体现。

初始标记阶段必须 STW

初始标记，可以理解为一次“闪电战”。它的任务非常聚焦：只标记那些与GC Roots直接关联的对象，也就是第一层引用。比如：

• 虚拟机栈中引用的局部变量对象
• 本地方法栈中JNI引用的对象
• 方法区中静态字段引用的对象
• 方法区中常量池引用的对象

由于只做一层快速扫描，这个阶段的停顿时间极短，通常控制在毫秒级别。但为什么必须暂停呢？道理很简单：为了保证标记起点的准确性，必须冻结用户线程，拍下一张瞬间的、一致的“内存快照”。如果用户线程还在跑，这个根对象集合就可能变来变去，标记也就无从谈起了。

并发标记阶段无需 STW

初始标记完成后，CMS就进入了最耗时的环节——并发标记。这个阶段，垃圾收集器线程会从刚才标记的根对象出发，像蜘蛛网一样，递归遍历整个对象图，把所有可达的存活对象都找出来并打上标记。

关键在于，这个过程是与用户线程并发执行的。也就是说，你的应用服务可以照常运行，不会因为垃圾收集而中断。当然，天下没有免费的午餐，并发标记虽然避免了停顿，但耗时较长，并且会因为与用户线程交替工作而消耗一部分CPU资源。

重新标记阶段必须 STW

并发标记阶段用户线程没停，这就带来了一个新问题：在漫长的标记过程中，用户线程可能修改了某些对象的引用关系，导致一些对象“漏标”或者“误标”。

这时候，就需要“重新标记”阶段来收尾了。它的任务就是进行一次最终的修正，处理那些在并发标记期间发生变动的对象。这个阶段必须再次暂停所有用户线程，以确保能获得一个准确的最终标记结果。虽然它的耗时比初始标记要稍长一些，但相比并发标记，仍然是一次非常短暂的强制暂停。

并发清除阶段无需 STW

标记工作全部完成后，最后一步就是清理。在并发清除阶段，收集器会根据最终的标记结果，直接清理掉那些被判定为死亡的对象。由于CMS是一款“标记-清除”算法收集器，它并不移动存活对象，所以这个清理过程也可以安全地与用户线程并发进行，不会引发全局暂停。

总结一下，CMS的设计思路非常清晰：把最耗时的“标记”和“清除”工作尽可能放到并发阶段去完成，只保留两次不可避免的、但极其短暂的轻量级暂停。这正是它当年被誉为“低延迟收集器”的底气所在。当然，这种设计也带来了内存碎片等问题，那就是另一个需要权衡的故事了。