漏标本质是用户线程与gc线程并发导致引用变更未同步，使存活对象被误判为垃圾；必须同时满足黑色对象新增指向白色对象的引用和原有灰色路径被切断两个条件，cms用增量更新、g1用satb、zgc/shenandoah用读屏障应对。
并发标记阶段的漏标问题，本质是用户线程和 GC 线程同时运行时，对象引用关系发生变更，而标记状态未能及时同步，导致本该存活的对象被错误地判为垃圾——这是三色标记算法在并发场景下最危险的隐患。
漏标是怎么发生的
三色标记要求：黑色对象不能直接引用白色对象（即“黑-白断链”）。一旦违反，就说明有对象被跳过标记，即“漏标”。典型场景有两类：
- 新增引用：用户线程新建了一条从黑色对象到白色对象的引用（比如 A 已标记为黑，B 还是白，此时 A 新增引用 B），而 GC 线程不会再扫描 A，B 就永远保持白色，最终被回收
- 删除引用：灰色对象正在遍历其引用时，用户线程将其某个引用（指向白色对象 C）删掉了；若 C 此前只被这个灰色对象引用，又没被其他路径覆盖，C 就会变成孤立的白色对象，被误判为垃圾
为什么说这是“致命”隐患
它不是内存泄漏，而是静默销毁存活对象。被误删的对象可能正被业务逻辑使用，比如某个订单数据、缓存中的 Session、正在处理的请求上下文——一旦被回收，后续访问将触发 NullPointerException 或逻辑错乱，且难以复现和定位。
这类问题不会立刻报错，往往在高并发、长周期运行后才暴露，属于典型的“并发安全漏洞”，比内存溢出更隐蔽、更难调试。
主流回收器怎么应对漏标
核心思路是：在并发标记结束后，用“重新标记”阶段兜底，但具体策略不同：
- CMS：采用写屏障（Write Barrier）+增量更新（Incremental Update），在引用被修改时，把被引用对象（如上面的 B）标记为灰色，确保它后续会被扫描
- G1：同样用写屏障，但采用原始快照（SATB, Snapshot-At-The-Beginning），在引用被删前，先记录下旧引用（如 C），保证它至少被当前标记周期覆盖一次
- ZGC/Shenandoah：通过读屏障（Load Barrier）在对象访问时动态检查并修正标记状态，实现更激进的并发性
开发中能做什么
虽然底层由 JVM 保障，但代码习惯会影响漏标风险的暴露概率：
- 避免在并发修改共享对象图的同时，频繁变更深层引用关系（例如在 HashMap.put 过程中动态替换 value 的引用链）
- 减少大对象或长生命周期对象的“中途挂载”，比如往一个已标记为黑的缓存容器里动态添加新元素
- 监控 GC 日志中的 Remark 阶段耗时——如果它显著增长，往往意味着漏标修正工作变重，可能是应用引用模式触发了更多写屏障开销
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
