增量更新通过写屏障拦截“黑色→白色”新引用，将其记录并在重新标记阶段让黑色对象退色为灰色重扫，从而防止对象消失；cms采用该机制，以可控stw代价换取低延迟，但可能产生浮动垃圾。

增量更新机制是应对并发可达性分析中“漏标”问题的核心手段之一，它不靠暂停用户线程，而是通过写屏障（Write Barrier）在引用关系变更的瞬间介入，主动干预标记状态，从而保障三色标记的正确性。

漏标为何必须被拦截

并发标记时，用户线程与GC线程并行运行。若一个白色对象C原本仅被灰色对象B引用，而B在扫描中途断开了对C的引用，同时黑色对象A又新增了对C的引用——此时C将永远停留在白色集合中，被误判为垃圾回收，引发严重逻辑错误。这种“对象消失”只在两个条件叠加时发生，而增量更新专门针对其中第一个条件：黑色对象插入指向白色对象的新引用。

增量更新怎么工作

它在每次发生“黑色 → 白色”引用写入时触发写屏障，把该引用记录进一个增量队列（如CMS中的“mod-union table”），并不立即重扫，而是留待并发标记结束后、进入“重新标记（Remark）”阶段统一处理：

• 所有新插入的黑色→白色引用，都会让黑色对象“退色”为灰色，表示它还有未完成的扫描任务
• 重新标记阶段会以这些灰色对象为起点，再次做局部深度遍历，确保C及其下游对象被正确标记
• 这个阶段仍需STW，但范围极小、耗时可控，远低于全堆遍历

它和原始快照（SATB）的关键区别

增量更新是“向前看”：发现新引用就补救；而G1等用的SATB是“向后看”：在灰色对象删除引用前，先快照下当时的引用关系，保证被删的白色对象不会真正丢失可达性。

• CMS采用增量更新，适合关注低延迟、能接受少量浮动垃圾的场景
• 它不改变原有标记流程主干，只在写操作处轻量埋点，工程实现相对直接
• 代价是可能多标（比如C后来又被其他线程释放，但它已被标记为存活），即产生浮动垃圾，但无功能风险

实际调优中如何感知它的存在

虽然开发者不直接编码控制增量更新，但在JVM参数和日志中可间接观察其作用：

• CMS开启并发标记时（-XX:+UseConcMarkSweepGC），GC日志中“remark”阶段耗时突增，往往说明增量队列积压较多新引用，需关注业务是否高频修改长链引用
• 若发现remark时间不稳定，可配合-XX:CMSInitiatingOccupancyFraction提前触发GC，减少并发阶段压力
• 注意：JDK 9+已废弃CMS，但理解其增量更新逻辑，对掌握ZGC、Shenandoah中更精细的读写屏障设计仍有迁移价值