写屏障机制原理
1. 核心概念与工作原理
并发 GC 最大的难题不是"如何快"，而是"如何对"。当 GC 扫描与用户 goroutine 同时运行时，用户 goroutine 改写指针的瞬间可能让 GC 漏标存活对象。这就需要一种机制——每当用户程序执行指针赋值时，额外做一点工作来通知 GC：“嘿，这里发生了一次指针改动，请别把它当成垃圾”。这种"额外工作"就是写屏障（write barrier）。
写屏障要解决的具体问题是上一篇提到的"对象丢失"（lost object）：
一个已经涂黑的对象 X 在标记期间新增指向白色对象 Y 的指针。
X 不会被重扫，Y 又没入队 → Y 被错误回收。
屏障的设计目标只有一个：在并发标记期间维持"黑不能直指白"的不变性。只要不变性成立，三色算法就能安全运行。
2. 两种经典写屏障
2.1 Dijkstra 插入屏障（Insertion Barrier）
由 Edsger Dijkstra 等人在 1978 年的论文On-the-fly garbage collection中提出，思路最直观：任何时候把一个白色对象写入到另一个对象时，把被写入的白对象立刻涂灰。这样下次扫描时一定会经过它，不变性得到维护。
写入操作obj.field = ptr（ptr 当前为白） | 屏障动作 |
|---|---|
| 插入屏障（Go 1.7 及之前） | ptr.color = 灰色 |
优点：实现简单，只需在赋值时检查并涂色。
缺点：必须额外扫描所有栈（因为栈上的指针写入不经过编译器插桩的屏障），所以 Go 1.7 之前每次 GC 仍需要一次 STW 来重扫栈。
2.2 Yuasa 删除屏障（Deletion Barrier）
由 T. Yuasa 1990 年提出，思路反过来：删除一个白色指针时把被删对象涂灰。等价语义是：覆盖指针前先把"即将被覆盖掉的那个旧指针"涂灰，确保旧对象至少还有一次被扫描到的机会。
写入操作obj.field = newPtr（覆盖obj.field） | 屏障动作 |
|---|---|
| 删除屏障 | 若obj.field旧值是白，则涂灰它 |
优点：无需重扫栈，因为"被删"指针已经被涂灰，再无人引用也仍然可达于本轮。
缺点：开销略高于插入屏障（每次写都需记旧值），但对栈扫描友好。
2.3 Go 1.8+ 的混合写屏障（Hybrid Write Barrier）
Go 1.8 之后采用Yuasa 删除屏障 + Dijkstra 插入屏障的混合版，由 Richard Hudson 在Getting to Go演讲中阐述：
- 插入部分：写指针时把被写入对象涂灰（保证新对象入队）
- 删除部分：写指针时把旧指针所指对象涂灰（保证旧对象不丢）
- 栈的特殊处理：GC 开始时把所有栈上的可达指针也涂灰一次，作为额外保护
这样 Go 不再需要 STW 阶段重扫栈，整个标记阶段几乎完全并发，代价是屏障本身的开销（每条指针写多一次条件判断）。Go 1.8 的基准测试显示这一改动让 GC 暂停时间从毫秒级降到 100 微秒级——这是 Go 延迟"质变"的分水岭。
3. 深度代码演练（完整可运行示例）
下面用一个串行化分步模拟，对比"无屏障 / 有插入屏障"两种情况下并发标记对同一图形的处理结果。
packagemainimport"fmt"varcolorName=[]string{"白","灰","黑"}// Obj 表示一个对象，颜色：0=白 1=灰 2=黑typeObjstruct{namestringrefs[]*Obj colorint}// Mark 是带显式 step 接口的标记器，方便在"中途插入用户行为"typeMarkstruct{queue[]*Obj}func(m*Mark)push(o*Obj){ifo.color==0{// 仅白入队o.color=1m.queue=append(m.queue,o)}}// step 取一个灰对象涂黑，并把它指向的白对象涂灰入队func(m*Mark)step()bool{iflen(m.queue)==0{returnfalse}cur:=m.queue[0]m.queue=m.queue[1:]cur.color=2for_,r:=rangecur.refs{m.push(r)}returntrue}funcrunScenario(withBarrierbool){fmt.Printf("\n=== 场景：A(黑) 在标记期间新增指向 E(白) 的指针 barrier=%v ===\n",withBarrier)a:=&Obj{name:"A"}b:=&Obj{name:"B"}c:=&Obj{name:"C"}e:=&Obj{name:"E"}// 标记中途被新增引用a.refs=[]*Obj{c}c.refs=[]*Obj{b}m:=&Mark{}m.push(a)// 根 A 入队fmt.Println("步骤1:",m.step()," → A 已涂黑，C 入队")fmt.Println("步骤2:",m.step()," → C 已涂黑，B 入队")// 关键点：用户程序在标记期间修改 A 的引用a.refs=append(a.refs,e)ifwithBarrier{// Dijkstra 插入屏障：写入指针时，把被写入的对象涂灰m.push(e)fmt.Println("写屏障触发：E 被涂灰并入队")}// 继续扫完队列form.step(){}fmt.Println("最终颜色:")for_,o:=range[]*Obj{a,b,c,e}{fmt.Printf(" %s = %s\n",o.name,colorName[o.color])}ife.color==2{fmt.Println("=> E 存活，GC 正确")}else{fmt.Println("=> E 仍为白色，将被回收 ⇒ 悬挂指针 BUG!")}}funcmain(){runScenario(false)runScenario(true)}运行结果：
=== 场景：A(黑) 在标记期间新增指向 E(白) 的指针 barrier=false === 步骤1: true → A 已涂黑，C 入队 步骤2: true → C 已涂黑，B 入队 最终颜色: A = 黑 B = 黑 C = 黑 E = 白 => E 仍为白色，将被回收 ⇒ 悬挂指针 BUG! === 场景：A(黑) 在标记期间新增指向 E(白) 的指针 barrier=true === 步骤1: true → A 已涂黑，C 入队 步骤2: true → C 已涂黑，B 入队 写屏障触发：E 被涂灰并入队 最终颜色: A = 黑 B = 黑 C = 黑 E = 黑 => E 存活，GC 正确4. 关键解读
4.1 屏障到底开在哪儿？
Go 用编译器插桩（compile-time instrumentation）实现屏障。源代码里obj.field = ptr这条赋值会被编译器翻译成带屏障的版本：
// 伪代码：编译器生成 if writeBarrier.enabled { gcWriteBarrier(ptr, &obj.field) }普通指针赋值会被改写；unsafe.Pointer转换和汇编手写赋值要靠程序员自觉调用runtime.SetFinalizer/runtime.KeepAlive或显式屏障辅助函数——这是另一个常见陷阱。
4.2 屏障的代价
屏障让每条指针写入多一次分支与写缓冲。基准上 Go 程序因为屏障会损失 1–5% 的吞吐（典型），换来的是 GC 暂停从毫秒级降到亚毫秒级。对延迟敏感的服务，这种交换非常划算；但对于延迟极不敏感、极致吞吐的纯计算场景（如离线批处理），有时反而要调高 GOGC 来减少 GC 次数。
4.3 屏障与终结器的关系
注意一个易错点：如果对象有SetFinalizer，GC 在回收它之前必须把它放入终结队列并运行终结函数。由于终结队列在标记期间也是被扫描的根，所以终结器本身也受写屏障保护；但循环引用 + 终结器的对象不会被回收（终结器引用形成外部根），这是另一个常见陷阱。
5. 小结
| 屏障类型 | 触发动作 | 主要优点 | 主要缺点 |
|---|---|---|---|
| Dijkstra 插入 | 写入指针时把被写入对象涂灰 | 实现最简单 | 需 STW 重扫栈 |
| Yuasa 删除 | 覆盖指针时把旧指针所指对象涂灰 | 无需 STW 重扫栈 | 开销略高 |
| 混合写屏障 | 插入 + 删除 + 启动时涂灰栈 | 完全并发标记 | 每条指针写多一次开销 |
