写屏障机制原理

写屏障机制原理

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. 深度代码演练（完整可运行示例）

下面用一个串行化分步模拟，对比"无屏障 / 有插入屏障"两种情况下并发标记对同一图形的处理结果。

package main

import "fmt"

var colorName = []string{"白", "灰", "黑"}

// Obj 表示一个对象，颜色：0=白 1=灰 2=黑
type Obj struct {
	name  string
	refs  []*Obj
	color int
}

// Mark 是带显式 step 接口的标记器，方便在"中途插入用户行为"
type Mark struct {
	queue []*Obj
}

func (m *Mark) push(o *Obj) {
	if o.color == 0 { // 仅白入队
		o.color = 1
		m.queue = append(m.queue, o)
	}
}

// step 取一个灰对象涂黑，并把它指向的白对象涂灰入队
func (m *Mark) step() bool {
	if len(m.queue) == 0 {
		return false
	}
	cur := m.queue[0]
	m.queue = m.queue[1:]
	cur.color = 2
	for _, r := range cur.refs {
		m.push(r)
	}
	return true
}

func runScenario(withBarrier bool) {
	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)
	if withBarrier {
		// Dijkstra 插入屏障：写入指针时，把被写入的对象涂灰
		m.push(e)
		fmt.Println("写屏障触发：E 被涂灰并入队")
	}

	// 继续扫完队列
	for m.step() {
	}

	fmt.Println("最终颜色:")
	for _, o := range []*Obj{a, b, c, e} {
		fmt.Printf("  %s = %s\n", o.name, colorName[o.color])
	}
	if e.color == 2 {
		fmt.Println("=> E 存活，GC 正确")
	} else {
		fmt.Println("=> E 仍为白色，将被回收 ⇒ 悬挂指针 BUG!")
	}
}

func main() {
	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 重扫栈	开销略高
混合写屏障	插入 + 删除 + 启动时涂灰栈	完全并发标记	每条指针写多一次开销