重标记阶段的核心任务是修正并发标记期间因用户线程运行导致的引用变动，防止漏标：通过写屏障+增量更新将“黑→白”赋值的对象变灰并重新扫描，同时扫描新生代存活对象以补全跨代引用，但需STW且无法覆盖所有变动。
重标记阶段的核心任务不是处理“存量变量变动”，而是修正并发标记过程中因用户线程持续运行而产生的引用关系变更，防止漏标导致对象被错误回收。
为什么需要重标记
并发标记阶段与用户线程同时运行，期间可能发生以下两类关键变动：
- 一个已标记为黑色的对象（认为其所有引用都已扫描完毕），被用户线程修改了某个字段，指向了一个白色对象（尚未被访问）——这会破坏三色标记的约束条件（黑→白），造成“漏标”
- 新生代发生 Young GC，部分存活对象晋升到老年代，这些新晋对象未被并发标记阶段覆盖
- 老年代中对象的引用被更新（如集合 add、map put、数组赋值等），新增了对白色对象的引用
重标记如何识别并处理这些变动
CMS 主要依赖写屏障（Write Barrier）配合增量更新（Incremental Update）策略，在并发标记期间记录可疑引用变更，供重标记阶段集中扫描：
- 当用户线程执行对象字段赋值（如
obj.field = newObj）时，写屏障会拦截该操作，若原对象已是黑色且被赋值的对象是白色，则将原对象重新标记为灰色（“变灰”），加入待扫描队列 - 这些被“变灰”的对象及其后续可达路径，会在重标记阶段被多线程并发扫描，确保其引用链上的所有存活对象最终都被标记为黑色
- 同时，重标记还会扫描新生代中仍存活的对象（特别是那些持有老年代引用的），补全跨代引用带来的遗漏
重标记的局限与代价
该阶段虽能大幅降低漏标风险，但无法做到 100% 覆盖：
- 写屏障本身有性能开销，JVM 会做裁剪优化，某些间接引用（如通过反射、JNI 或非常规内存操作）可能绕过检测
- 增量更新只记录“黑→白”的写操作，不处理“灰→白”或“白→白”等其他变动模式
- 重标记必须 STW，耗时取决于“变灰”对象数量和跨代引用规模；若并发标记耗时过长或系统负载高，重标记时间可能显著上升
实际调优关注点
减少重标记压力的关键在于控制并发标记阶段的不确定性：
- 降低老年代对象间频繁修改引用的频率（如避免在老年代大对象中高频更新集合/缓存结构）
- 合理设置
-XX:CMSInitiatingOccupancyFraction，避免 CMS 启动过晚，导致并发标记时老年代已接近饱和、变动剧烈 - 配合使用
-XX:+CMSScavengeBeforeRemark，让重标记前先触发一次 Young GC，减少需扫描的跨代引用数量 - 监控日志中的
[GC (CMS Remark)持续时间，若明显增长，说明并发标记期间变动过大，需结合业务逻辑排查
