Final Remark本质是终结并发标记的不确定性，必须STW以获得全局一致内存视图，通过扫描卡表等机制精确补全漏标对象，确保标记集严格等于可达对象集，这是唯一能将漏标概率压至0的数学必然选择。
Final Remark（重新标记）不是为了“补全”标记，而是为了封账——在并发标记结束的那一刻，系统必须冻结所有引用变更，确保标记结果与真实存活状态严格一致。它必须 STW，不是权宜之计，而是可达性分析在并发环境下的数学必然性。
Final Remark 的本质：解决并发导致的“漏标”不可判定性
并发标记阶段中，应用线程持续修改对象图（如将 A 引用赋给 B、新建对象并立即被引用），GC 线程无法原子性地捕获所有中间状态。这导致一个根本性问题：某些本应存活的对象，在并发标记中未被扫描到（即“漏标”）。而漏标在数学上无法通过异步观察完全避免——因为任意时刻的引用快照都可能被下一纳秒的写操作覆盖。
Final Remark 就是这个不确定性的终结点：它强制暂停所有应用线程，以获得一个全局一致的内存视图。此时 GC 线程可安全遍历所有在并发标记期间发生过变动的区域（如通过卡表记录的脏页），对新产生的引用关系做一次性、确定性的补充扫描。
为什么不能靠“多轮并发标记”替代 STW？
理论上可以反复并发标记，但收敛性无保障：
- 每次并发标记耗时 T，而应用线程在 T 内产生的新引用变动量呈正相关增长；
- 若变动率 λ > 1/T，则标记永远追不上变更，陷入无限循环；
- 即使 λ 较低，N 轮后残留漏标概率为 (1−p)ᴺ，趋近于 0 的速度受制于实际停顿容忍度——而业务通常只允许一次毫秒级可控停顿，而非多次不可控延迟。
STW 是唯一能将漏标概率精确压至 0 的操作，具备确定性上界（例如 ≤5ms），这是任何纯并发策略无法提供的数学保证。
STW 的底层支撑：安全点与三色标记的完整性约束
CMS 使用三色标记法（白-未访问、灰-已标记待扫描、黑-已扫描完成）。并发标记中，若应用线程执行“黑色对象新增白色引用”，就会破坏“黑→白”不可逆的不变式，造成漏标。
Final Remark 在所有线程抵达安全点后执行，此时：
- 每个线程栈帧中的局部变量、寄存器引用均处于稳定状态；
- 所有跨代引用（如新生代对象引用老年代）已完成快照；
- 卡表中标记的脏页可被完整扫描，补全所有“灰→白”断裂路径。
这一过程满足形式化验证中的“强一致性条件”：标记集合 M 满足 M = {o | ∃path from GC Roots to o}，即最终标记集严格等于可达对象集——该等式仅在全局暂停下可被构造和验证。
不 STW 的代价：浮动垃圾 vs. 误回收，系统选择前者
如果不做 Final Remark 或不 STW，CMS 只能保守处理——要么把所有并发期间变动过的对象都当作存活（大幅增加浮动垃圾，浪费内存），要么冒险清除（导致对象提前回收，引发 crash 或数据错乱）。前者影响吞吐，后者破坏正确性。
数学上，STW 停顿时间 t 是可控小量（O(log n) 量级，n 为脏页数），而误回收概率若非零，则系统可靠性下限为 0。因此 JVM 选择用确定的小代价，换取确定的语义正确性。
