在并发垃圾回收技术中，三色标记算法是实现高效并发的基石。该算法允许用户线程与标记线程同时执行，但“并发”本身也带来了一个经典挑战：漏标。即当标记线程正在遍历对象图时，用户线程动态修改了对象间的引用关系，可能导致本应存活的对象被错误地判定为垃圾（白色对象）并回收。
漏标风险通常源于一个特定的并发操作序列：首先，一个已被标记为黑色（表示已扫描完成）的对象，新增了一个指向白色（尚未访问）对象的引用；与此同时，原本指向该白色对象的某个灰色（待扫描）对象，恰好删除了这条引用。这样，白色对象既失去了来自灰色对象的可达路径，又因为黑色对象不会再次被扫描而无法被标记，最终成为“漂浮的垃圾”。
为解决这一并发一致性问题，现代垃圾收集器引入了多种写屏障技术。其核心思想是在对象引用关系被修改的关键路径上设置“关卡”，通过不同的策略确保标记过程的正确性，防止存活对象丢失。
插入写屏障：拦截新增引用，即时标记灰色
插入写屏障采取“预防为主”的策略。当用户线程执行类似 obj.field = newRef 的写操作，且目标对象（obj）为黑色、被引用对象（newRef）为白色时，屏障会立即触发。其核心动作是：将被引用的白色对象直接标记为灰色，并加入待扫描队列。
这相当于在数据流的关键路口设立检查点，一旦发现已扫描对象试图引用未扫描对象，便立即为后者贴上“待处理”标签。通过即时介入，它彻底阻断了“黑色引用白色”这一危险路径，确保白色对象不会因被黑色对象引用而脱离扫描范围。
需要注意的是，出于性能考虑，此类屏障通常仅作用于堆内存的对象引用更新，栈上的局部变量赋值则不受影响。因此，早期Go语言采用纯插入屏障时，仍需在GC开始时进行一次短暂的全局停顿（STW）以完成栈扫描，保证一致性。此外，这种“保守标记”策略可能带来一定的冗余扫描开销，因为被提前标灰的对象后续仍可能被正常扫描。
删除写屏障（SATB）：维护快照视图，保留历史引用
与插入屏障的“堵截”思路不同，删除写屏障（Snapshot At The Beginning, SATB）更侧重于“保全”。它不关注谁新增了引用，而是紧盯谁断开了引用。
当用户线程准备执行类似 greyObj.field = whiteObj 的删除操作（即将断开灰色对象对白色对象的引用）时，删除屏障会在操作前介入。它不会阻止删除发生，但会将被断开的白色对象记录到SATB队列，并标记为灰色。
这一机制的巧妙之处在于，它为标记阶段维护了一份“逻辑快照”。回收器以标记开始时刻的对象引用关系作为基础视图，所有在该视图下可达的对象，即使后续引用被删除，也会因被屏障提前记录并标灰而得以保留。此策略特别适用于写操作频繁但新对象创建较少的场景。其代价是需要额外内存维护变更记录。
混合写屏障：Go语言的平衡之道
在实践了纯插入屏障与类SATB机制后，Go语言从1.8版本起采用了一种更为精巧的混合写屏障策略，可视为前两种思路的融合与优化。
其规则统一而简洁：任何发生在堆上的写操作（无论是赋值 a.field = b 还是置空 a.field = nil），都会触发屏障，并将被写入的目标对象（即b，或被覆盖的原值）标记为灰色。
这种设计带来了多重优势：
- 消除栈扫描STW：由于新分配对象默认标记为黑色，且栈上写操作也会触发屏障，保证了堆栈状态的一致性，从而彻底免除了专门扫描栈的全局停顿。
- 平衡性能开销：它避免了SATB可能产生的大量日志内存占用，也减少了纯插入屏障导致的过度扫描，在内存与CPU开销间取得较好平衡。
- 实现极低延迟：得益于此机制，Go可以将GC的停顿时间压缩至百微秒级别，这对于高并发、低延迟的后端服务至关重要。
增量更新：JVM的经典后置处理策略
另一种广泛用于JVM（如CMS、G1收集器）的策略是增量更新。其哲学可概括为“先允许变更，后集中修复”。
在并发标记阶段，它并不实时阻止“黑色引用白色”的情况发生。写屏障仅负责记录所有产生此类引用的黑色对象。随后，在标记阶段结束、清理开始前，GC会启动一个“再标记”阶段。此阶段以之前记录的黑色对象为新的根，重新进行一轮扫描，追踪那些可能被遗漏的白色对象。
这类似于先开放交通，再集中处理违章。其优点是对用户线程的运行时干扰最小，屏障操作通常更轻量。缺点是拉长了整个GC周期的总耗时，并可能产生浮动垃圾。因此，该策略更适合对吞吐量敏感、可容忍稍长延迟的批处理或计算密集型应用。
总结而言，没有一种屏障策略是万能的。插入屏障直接高效，删除屏障保守安全，混合屏障寻求平衡，增量更新则以时间换空间。选择何种方案，最终取决于系统在延迟、吞吐量、内存开销及实现复杂度之间的权衡。深入理解它们如何协同工作以切断“漏标”路径，是掌握现代并发垃圾回收器设计精髓的关键。
