CMS (Concurrent Mark Sweep) 深度解剖：分析并发标记与并发清理阶段的变量不一致风险

CMS的并发标记与并发清理阶段，确实存在变量不一致的风险。其核心矛盾在于：用户线程在持续修改引用关系，而垃圾回收线程却按照自己的节奏推进标记和清理。这两者不同步，就会破坏三色标记算法赖以成立的基本前提。不过，这种不一致并非表现为随机、不可预测的错乱，而是有明确的触发条件和对应的防护机制。问题的关键，往往在于“漏标”，而非“误删”。

漏标发生的两个硬性前提

在三色标记模型中，黑色对象意味着“已处理完毕”，其引用关系被默认是冻结的。一旦一个黑色对象在标记完成后，又新增了一个指向白色对象的引用，且没有补偿机制，漏标就发生了。但仅仅有新增引用还不够，必须同时满足两个条件：

• 前提一：一个黑色对象 A 在标记完成后，执行了 A.field = B 的操作，而 B 此时恰好是白色对象。
• 前提二：原本能将 B 对象带出（即标记为存活）的灰色路径被切断了。例如，灰色对象 C 原本持有对 B 的引用，此时执行了 C.field = null。

两者缺一不可。如果只发生新增引用，B 对象仍有可能通过其他灰色对象被带入扫描范围；如果只发生引用删除，B 对象若本身已被标记或仍有其他引用路径，也不会被遗漏。只有当“黑→白”的新增引用与“灰→白”的路径断裂同时发生时，三色不变式才被真正打破，导致漏标。

写屏障如何实时拦截新增引用

CMS 采用增量更新策略来应对这个问题，其核心是依赖写屏障在赋值操作后即时介入。整个过程是这样的：

• 当 JVM 执行类似 objA.field = objB 的赋值语句时，写屏障会检查。如果发现 objA 是黑色对象，而 objB 是白色对象，写屏障会立即捕获这次操作。
• 随后，它会将黑色对象 objA 重新标记为灰色，并将这条新增的引用关系（A → B）记录到一个特殊的增量更新队列中。
• 等到重新标记阶段（需要短暂的 STW）时，GC 线程会扫描这个队列，并以被重新标记为灰色的 objA 为起点，重新进行遍历扫描，从而发现并标记 objB 及其所有可达对象。

这个过程不依赖时间戳或全局快照，是一种即时响应的“事后补救”机制。它确保了所有被黑色对象新“拉进”关系网的存活对象，都能在最终标记阶段被覆盖到。

为什么引用删除不被处理——CMS 的设计取舍

值得注意的是，CMS 明确选择不记录、也不回溯引用删除的动作。举个例子，如果灰色对象 C 删除了对白色对象 E 的引用，而 E 之后再也没有其他引用路径，那么 E 就会永远停留在白色状态，并在后续被当作垃圾回收掉。

• 这种因引用删除导致的漏标，无法在重新标记阶段修复，因为系统没有任何机制知道“C 曾经引用过 E”。
• 这是 CMS 主动接受的一个代价：用允许产生少量“浮动垃圾”为交换，来换取更短的 STW 时间。
• 这并非设计缺陷，而是一种工程上的权衡。对比之下，G1 收集器采用的 SATB 算法会试图覆盖引用删除的场景，但代价是更高的写屏障开销和内存占用。

并发清理阶段的“安全边界”在哪

并发清理阶段本身并不会产生新的漏标问题，但它会放大标记阶段遗留问题的影响：

• 清理阶段只清除那些在“重新标记阶段结束时”被确认为垃圾的对象，它不会重新扫描堆内存。因此，标记阶段因写屏障保护而未被漏标的存活对象，是安全的，不会被误删。
• 但是，那些在标记阶段就该被回收、却因各种原因（如未被扫描到）而没被标记上的垃圾对象，会在清理阶段被跳过，从而成为“浮动垃圾”堆积在老年代。
• 浮动垃圾积累得越多，老年代可用空间就越紧张，也就越容易触发“并发模式失败”。所以，这里的关键风险不在于“清错了”，而在于“清不干净”，其根源依然可以追溯到并发标记阶段的状态同步是否足够严密。

漏标需同时满足“黑→白”新增引用和原灰色路径被切断；CMS用增量更新写屏障捕获新增引用并重新标记黑色对象为灰色，但不处理引用删除，以换取更短STW。