SATB通过“初始快照+写前屏障”防漏标：仅在灰色对象删除对白色对象的引用前，将旧引用压入SATB队列，Remark阶段以此为根重扫，确保不漏标；新增引用由三色标记自然覆盖，浮动垃圾是可控代价。

要讲清 G1 的 SATB 与写屏障在并发标记阶段如何联手防漏标，关键得抓住一个核心逻辑：不是靠“补全所有变化”，而是精准掐断漏标发生的必要条件。

SATB 的本质是“冻结快照”，不是记录全部引用变更

SATB 全称 Snapshot At The Beginning，指在并发标记开始那一刻，就认为堆中所有存活对象的引用关系已被“拍下快照”。后续用户线程（Mutator）对引用的修改——尤其是灰色对象删除对白色对象的引用——会被视为对快照的“破坏”。G1 不试图跟踪所有新增引用，只重点捕获那些可能引发漏标的“删”操作。

• 漏标必须同时满足两个条件：黑色对象新增指向白色对象的引用；且所有灰色对象都删掉了对该白色对象的引用
• SATB 主动破坏第二个条件：只要灰色对象删掉一个指向白色对象的引用，就立刻通过写屏障把该引用“记下来”
• 这些被记录的引用，在最终标记（Remark）阶段统一作为根再扫描一遍，确保对应白色对象不会被漏掉

写屏障是 SATB 落地的执行开关

写屏障不是泛泛而谈的“拦截”，G1 用的是 pre-write barrier（写前屏障）。它插在赋值语句真正执行之前，例如 obj.field = null 这类可能导致引用丢失的操作前。

• 当检测到即将删除一个非空引用（即旧值不为 null），且该引用目标是白色对象时，屏障会触发：把该引用推入 SATB 日志缓冲区
• 日志结构轻量（通常是环形缓冲区+本地线程队列），避免高并发下锁争用
• Remark 阶段只需回放这些日志，以其中每个被删引用为目标，重新做一次小范围标记传播，无需重扫整个堆

三色标记与 SATB 协同，天然规避“增”的风险

为什么新增引用（比如灰色对象 C 新增指向白色对象 D）不需要记录？因为三色标记本身的推进规则已兜底：

• C 是灰色，说明它正在被扫描中；一旦 C 新增引用 D，GC 线程在后续遍历 C 的引用字段时，必然看到 D
• D 会被立即标灰、入队，进入待扫描队列，不会滞留在白色状态
• 只要 C 在变黑前完成对 D 的处理，D 就不可能漏标

浮动垃圾是这套机制的合理代价

SATB 记录的是“删”，但实际被保留下来的对象里，有些在标记结束后已不可达——比如 D 原本被 C 引用，C 删了它，但 SATB 日志把它保住了；之后再没人引用 D，它就成了本轮无法回收的浮动垃圾。

• 这是设计取舍：用少量浮动垃圾，换 Remark 阶段极短暂停
• 相比 CMS 的增量更新（需在每次新增引用时把黑色对象刷回灰色），SATB 日志量更少、更可控
• TAMS（Top-At-Mark-Start）指针配合 SATB，明确划分出“标记开始前已分配”和“标记中新增分配”的内存区域，进一步缩小需关注的范围