- 什么是屏障？
- golang 涉及到的三个写屏障
- 原理分析
- 示例分析代码
- 先看逃逸分析
- 写屏障真实的样子
什么是屏障？
承接上篇概述，下面讨论什么是写屏障？先说结论：
- 内存屏障只是对应一段特殊的代码
- 内存屏障这段代码在编译期间生成
- 内存屏障本质上在运行期间拦截内存写操作，相当于一个 hook 调用
golang 涉及到的三个写屏障
- 插入写屏障
- 删除写屏障
- 混合写屏障（旁白：其实本质上是两个，混合写屏障就是插入写屏障和删除写屏障的混合）
这三个名词什么意思？区别在哪里？
最本质的区别就是：我们说了，内存屏障其实就是编译器帮你生成的一段 hook 代码，这三个屏障的本质区别就是 hook 的时机不同而已。
原理分析
声明下，下面的例子使用的是 go1.13.3。
示例分析代码
一直说，写屏障是编译器生成的，先形象看下代码样子：
1 package main
2
3 type BaseStruct struct {
4 name string
5 age int
6 }
7
8 type Tstruct struct {
9 base *BaseStruct
10 field0 int
11 }
12
13 func funcAlloc0 (a *Tstruct) {
14 a.base = new(BaseStruct) // new 一个BaseStruct结构体，赋值给 a.base 字段
15 }
16
17 func funcAlloc1 (b *Tstruct) {
18 var b0 Tstruct
19 b0.base = new(BaseStruct) // new 一个BaseStruct结构体，赋值给 b0.base 字段
20 }
21
22 func main() {
23 a := new(Tstruct) // new 一个Tstruct 结构体
24 b := new(Tstruct) // new 一个Tstruct 结构体
25
26 go funcAlloc0(a)
27 go funcAlloc1(b)
28 }
这里例子，可以用来观察两个东西：
- 概述篇提到的逃逸分析
- 编译器插入内存屏障的时机
先看逃逸分析
为什么先看逃逸分析？
因为只有堆上对象的写才会可能有写屏障，这又是个什么原因呢？因为如果对栈上的写做拦截，那么流程代码会非常复杂，并且性能下降会非常大，得不偿失。根据局部性的原理来说，其实我们程序跑起来，大部分的其实都是操作在栈上，函数参数啊、函数调用导致的压栈出栈啊、局部变量啊，协程栈，这些如果也弄起写屏障，那么可想而知了，根本就不现实，复杂度和性能就是越不过去的坎。
继续看逃逸什么意思？就是内存分配到堆上。golang 可以在编译的时候使用 -m 参数支持把这个可视化出来：
$ go build -gcflags "-N -l -m" ./test_writebarrier0.go
# command-line-arguments
./test_writebarrier0.go:13:18: funcAlloc0 a does not escape
./test_writebarrier0.go:14:17: new(BaseStruct) escapes to heap
./test_writebarrier0.go:17:18: funcAlloc1 b does not escape
./test_writebarrier0.go:19:18: funcAlloc1 new(BaseStruct) does not escape
./test_writebarrier0.go:23:13: new(Tstruct) escapes to heap
./test_writebarrier0.go:24:13: new(Tstruct) escapes to heap
先说逃逸分析两点原则：
- 在保证程序正确性的前提下，尽可能的把对象分配到栈上，这样性能最好；
- 栈上的对象生命周期就跟随 goroutine ，协程终结了，它就没了
- 明确一定要分配到堆上对象，或者不确定是否要分配在堆上的对象，那么就全都分配到堆上；
- 这种对象的生命周期始于业务程序的创建，终于垃圾回收器的回收
我们看到源代码，有四次 new 对象的操作，经过编译器的“逃逸分析”之后，实际分配到堆上的是三次：
- 14 行 —— 触发逃逸（分配到堆上）
- 这个必须得分配到堆上，因为除了这个 goroutine 还要存活呢
- 19 行 —— 无 （分配到栈上）
- 这个虽然也是 new，单就分配到栈上就行，因为 b0 这个对象就是一个纯粹的栈对象
- 23 行 —— 触发逃逸 （分配到堆上）
- 这个需要分配到堆上，因为分配出来的对象需要传递到其他协程使用
- 24 行 —— 触发逃逸 （分配到堆上）
- 这次必须注意下，其实站在我们上帝视角，这次的分配其实也可以分配到栈上。这种情况编译器就简单处理了，直接给分配到堆上。这种就属于编译器它摸不准的，那么分配到堆上就对了，反正也就性能有点影响，功能不会有问题，不然的话你真分配到栈上了，一旦栈被回收就出问题了
写屏障真实的样子
再看下编译器汇编的代码：
从这个地方我们需要知道一个事情，go 的关键字语法呀，其实在编译的时候，都会对应到一个特定的函数，比如 new 这个关键字就对应了 newobject 函数，go 这个关键字对应的是 newproc 函数。贴一张比较完整的图：
从这个汇编代码我们也确认了，23，24行的对象分配确实是在堆上。我们再看下函数 funcAlloc0 和 funcAlloc1 这两个。
main.funcAlloc0
13 func funcAlloc0 (a *Tstruct) {
14 a.base = new(BaseStruct) // new 一个BaseStruct结构体，赋值给 a.base 字段
15 }
简单的注释解析：
(gdb) disassemble
Dump of assembler code for function main.funcAlloc0:
0x0000000000456b10 <+0>: mov %fs:0xfffffffffffffff8,%rcx
0x0000000000456b19 <+9>: cmp 0x10(%rcx),%rsp
0x0000000000456b1d <+13>: jbe 0x456b6f <main.funcAlloc0+95>
0x0000000000456b1f <+15>: sub $0x20,%rsp
0x0000000000456b23 <+19>: mov %rbp,0x18(%rsp)
0x0000000000456b28 <+24>: lea 0x18(%rsp),%rbp
0x0000000000456b2d <+29>: lea 0x1430c(%rip),%rax # 0x46ae40
0x0000000000456b34 <+36>: mov %rax,(%rsp)
0x0000000000456b38 <+40>: callq 0x40b060 <runtime.newobject>
# newobject的返回值在 0x8(%rsp) 里，golang 的参数和返回值都是通过栈传递的。这个跟 c 程序不同，c 程序是溢出才会用到栈，这里先把返回值放到寄存器 rax
0x0000000000456b3d <+45>: mov 0x8(%rsp),%rax
0x0000000000456b42 <+50>: mov %rax,0x10(%rsp)
# 0x28(%rsp) 就是 a 的地址：0xc0000840b0
=> 0x0000000000456b47 <+55>: mov 0x28(%rsp),%rdi
0x0000000000456b4c <+60>: test %al,(%rdi)
# 这里判断是否开启了屏障（垃圾回收的扫描并发过程，才会把这个标记打开，没有打开的情况，对于堆上的赋值只是多走一次判断开销）
0x0000000000456b4e <+62>: cmpl $0x0,0x960fb(%rip) # 0x4ecc50 <runtime.writeBarrier>
0x0000000000456b55 <+69>: je 0x456b59 <main.funcAlloc0+73>
0x0000000000456b57 <+71>: jmp 0x456b68 <main.funcAlloc0+88>
# 赋值 a.base = xxxx
0x0000000000456b59 <+73>: mov %rax,(%rdi)
0x0000000000456b5c <+76>: jmp 0x456b5e <main.funcAlloc0+78>
0x0000000000456b5e <+78>: mov 0x18(%rsp),%rbp
0x0000000000456b63 <+83>: add $0x20,%rsp
0x0000000000456b67 <+87>: retq
# 如果是开启了屏障，那么完成 a.base = xxx 的赋值就是在 gcWriteBarrier 函数里面了
0x0000000000456b68 <+88>: callq 0x44d170 <runtime.gcWriteBarrier>
0x0000000000456b6d <+93>: jmp 0x456b5e <main.funcAlloc0+78>
0x0000000000456b6f <+95>: callq 0x44b370 <runtime.morestack_noctxt>
0x0000000000456b74 <+100>: jmp 0x456b10 <main.funcAlloc0>
End of assembler dump.
所以，从上面简单的汇编代码，我们印证得出几个小知识点：
- golang 传参和返回参数都是通过栈来传递的（可以思考下优略点，有点是逻辑简单了，也能很好的支持多返回值的实现，缺点是比寄存器的方式略慢，但是这种损耗在程序的运行下可以忽略）；
- 写屏障是一段编译器插入的特殊代码，在编译期间插入，代码函数名字叫做
gcWriteBarrier； - 屏障代码并不是直接运行，也是要条件判断的，并不是只要是堆上内存赋值就会运行
gcWriteBarrier代码，而是要有一个条件判断。这里提前透露下，这个条件判断是垃圾回收器扫描开始前，stw 程序给设置上去的；- 所以平时对于堆上内存的赋值，多了一次写操作；
伪代码如下：
if runtime.writeBarrier.enabled {
runtime.gcWriteBarrier(ptr, val)
} else {
*ptr = val
}
说到 golang 传参数只用栈这点，这里就再深入挖掘一点，golang ABI（Application Binary Interface）标准就是这样的，传参数用栈，返回值也用栈。但是巧了，刚好，就有一些特例，我们今天遇到的 runtime.gcWriteBarrier 就是个特例，gcWriteBarrier 就故意违反了这个惯例，这里引用一段这汇编文件的注释：
// gcWriteBarrier performs a heap pointer write and informs the GC. // // gcWriteBarrier does NOT follow the Go ABI. It takes two arguments: // - DI is the destination of the write // - AX is the value being written at DI // It clobbers FLAGS. It does not clobber any general-purpose registers, // but may clobber others (e.g., SSE registers).
这里为了减少 GC 导致性能的损耗，使用了 rdi ，rax ，这两个寄存器来传参数：
- rdi ：堆内存写入的地址
- rax ：赋的值
我们继续看下 runtime·gcWriteBarrier 函数干啥的，这个函数是用纯汇编写的，举一个特定cpu集合的例子，在 asm_amd64.s 里的实现。这个函数只干两件事：
- 执行写请求
- 处理 GC 相关的逻辑
下面简单理解下 runtime·gcWriteBarrier 这个函数：
TEXT runtime·gcWriteBarrier(SB),NOSPLIT,$120
get_tls(R13)
MOVQ g(R13), R13
MOVQ g_m(R13), R13
MOVQ m_p(R13), R13
MOVQ (p_wbBuf+wbBuf_next)(R13), R14
LEAQ 16(R14), R14
MOVQ R14, (p_wbBuf+wbBuf_next)(R13)
// 检查 buffer 队列是否满？
CMPQ R14, (p_wbBuf+wbBuf_end)(R13)
// 赋值的前后两个值都会被入队
// 把 value 存到指定 buffer 位置
MOVQ AX, -16(R14) // Record value
// 把 *slot 存到指定 buffer 位置
MOVQ (DI), R13
MOVQ R13, -8(R14)
// 如果 wbBuffer 队列满了，那么就下刷处理，比如置灰，置黑等操作
JEQ flush
ret:
// 赋值：*slot = val
MOVQ 104(SP), R14
MOVQ 112(SP), R13
MOVQ AX, (DI)
RET
flush:
。。。
// 队列满了，统一处理，这个其实是一个批量优化手段
CALL runtime·wbBufFlush(SB)
。。。
JMP ret
思考下：不是说把 *slot = value 直接置灰色，置黑色，就完了嘛，这里搞得这么复杂？
最开始还真不是这样的，这个也是一个优化的过程，这里是利用批量的一个思想做的一个优化。我们再理解下最本质的东西，触发了写屏障之后，我们的核心目的是为了能够把赋值的前后两个值记录下来，以便 GC 垃圾回收器能得到通知，从而避免错误的回收。记录下来是最本质的，但是并不是要立马处理，所以这里做的优化就是，攒满一个 buffer ，然后批量处理，这样效率会非常高的。
| wbBuf 结构如下： |
|---|
| 8 |
| — |
每个 P 都有这么个 wbBuf 队列。
我们看到 CALL runtime·wbBufFlush(SB) ，这个函数 wbBufFlush 是 golang 实现的，本质上是调用 wbBufFlush1 。这个函数才是 hook 写操作想要做的事情，精简了下代码如下：
func wbBufFlush1(_p_ *p) {
start := uintptr(unsafe.Pointer(&_p_.wbBuf.buf[0]))
n := (_p_.wbBuf.next - start) / unsafe.Sizeof(_p_.wbBuf.buf[0])
ptrs := _p_.wbBuf.buf[:n]
_p_.wbBuf.next = 0
gcw := &_p_.gcw
pos := 0
// 循环批量处理队列里的值，这个就是之前在 gcWriteBarrier 赋值的
for _, ptr := range ptrs {
if ptr < minLegalPointer {
continue
}
obj, span, objIndex := findObject(ptr, 0, 0)
if obj == 0 {
continue
}
mbits := span.markBitsForIndex(objIndex)
if mbits.isMarked() {
continue
}
mbits.setMarked()
if span.spanclass.noscan() {
gcw.bytesMarked += uint64(span.elemsize)
continue
}
ptrs[pos] = obj
pos++
}
// 置灰色（投入灰色的队列），这就是我们的目的，对象在这里面我们就不怕了，我们要扫描的就是这个队列；
gcw.putBatch(ptrs[:pos])
_p_.wbBuf.reset()
}
所以我们总结下，写屏障到底做了什么：
- hook 写操作
- hook 住了写操作之后，把赋值语句的前后两个值都记录下来，投入 buffer 队列
- buffer 攒满之后，批量刷到扫描队列（置灰）（这是 GO 1.10 左右引入的优化）
main.funcAlloc1
17 func funcAlloc1 (b *Tstruct) {
18 var b0 Tstruct
19 b0.base = new(BaseStruct) // new 一个BaseStruct结构体，赋值给 b0.base 字段
20 }
最后，再回顾看下 main.funcAlloc1 函数，这个函数是只有栈操作，非常简单。
下一篇，继续讲述插入写屏障究竟是什么东西？
坚持思考，方向比努力更重要。关注公众号：奇伢云存储，获取更多干货。
