cms重标记阶段不全堆扫描，而是stw下精准补漏：通过写屏障捕获并发期“黑→白”赋值并变灰源对象，remark时递归扫描这些对象及其引用链，并扫描新生代存活对象补全跨代引用。
CMS 的重标记阶段（Remark）不重新扫描整个堆，而是聚焦于并发标记期间被用户线程修改过的引用关系，核心目标是堵住“黑→白”漏标漏洞，确保最终标记结果准确。它靠写屏障记录 + 增量更新策略 + STW 下的定向扫描协同完成，不是 brute-force 重扫，而是精准补漏。
写屏障实时捕获“黑→白”赋值
并发标记中，一旦对象被标记为黑色，GC 线程默认不再访问它。但用户线程可能执行 obj.field = whiteObj，让黑色对象指向一个白色对象——这直接破坏三色不变式，导致 whiteObj 漏标。
CMS 在每次字段赋值前插入写屏障，当检测到：
- 源对象已是黑色
- 目标对象仍是白色
- 且该引用跨代或涉及老年代（关键路径）
就立即把源对象重新标记为灰色，并加入待扫描队列。这个动作叫“变灰”，本质是打上“需复查”标签，不立即扫描，留到 Remark 阶段统一处理。
Remark 阶段只扫描可疑区域，不从 GC Roots 重头开始
Final Remark 是 STW 阶段，但它不遍历所有 GC Roots，也不对整个老年代做全量重标记。它集中处理三类内容：
- 所有被写屏障“变灰”的对象（即并发期间新增黑→白引用的源对象）
- 这些对象的全部引用字段（递归扫描其子图，把新可达对象也标记为灰色或黑色）
- 新生代中存活对象（特别是持有老年代引用的），通过卡表（Card Table）快速定位跨代引用，补全晋升漏标
例如：A 是黑色对象，在并发阶段被赋值 A.ref = B（B 是白色），写屏障将 A 变灰；Remark 时以 A 为起点扫描，发现 B 并标记为灰色，再扫描 B 的引用链，从而闭环。
预清理阶段提前消化浮动垃圾，减轻 Remark 压力
并发标记期间，部分对象已变为不可达但尚未回收，称为“浮动垃圾”。若等到 Remark 才清理，会拖慢停顿时间。
CMS 在 Remark 前插入可中断预清理（Abortable Preclean）阶段，完全并发执行，主要做两件事：
- 扫描并清除那些在并发标记过程中“刚变不可达”的对象（尤其是新生代晋升后又失效的老年代引用）
- 尝试触发一次 Young GC，缩小新生代规模，从而减少 Remark 需扫描的跨代引用数量
如果老年代占用增长过快，该阶段会主动中止，避免耽误 CMS 主周期——这是调优时观察 CMS-concurrent-abortable-preclean interrupted 日志的关键依据。
局限性：不处理引用删除，接受少量浮动垃圾
增量更新只响应“新增引用”，对“删除引用”无动于衷。比如灰色对象 C 原本引用白色对象 E，之后 C.ref = null，而 E 再无其他路径可达——E 就会漏标，成为浮动垃圾。
CMS 明确接受这种设计取舍：用可控的浮动垃圾换更短的 STW 时间。只要浮动垃圾能在下一轮 GC 中被回收，就不影响正确性，只是略微降低内存利用率。
