golang 垃圾回收 内存屏障篇

• 什么是屏障？

• golang 涉及到的三个屏障技术

• 原理分析

• 示例分析代码

• 先看逃逸分析

• 写屏障真实的样子

什么是屏障？

承接上篇概述，下面讨论什么是写屏障？先说结论：

1. 内存屏障只是对应一段特殊的代码
2. 内存屏障这段代码在编译期间生成
3. 内存屏障本质上在运行期间拦截内存写操作，相当于一个 hook 调用

golang 涉及到的三个屏障技术

1. 插入写屏障
2. 删除写屏障
3. 混合写屏障（旁白：其实本质上是两个，混合写屏障就是插入写屏障和删除写屏障的混合）

这三个名词什么意思？区别在哪里？

最本质的区别就是：我们说了，内存屏障其实就是编译器帮你生成的一段 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 }

这里例子，可以用来观察两个东西：

1. 概述篇提到的逃逸分析
2. 编译器插入内存屏障的时机

先看逃逸分析

为什么先看逃逸分析？

因为只有堆上对象的写才会可能有写屏障，这又是个什么原因呢？因为如果对栈上的写做拦截，那么流程代码会非常复杂，并且性能下降会非常大，得不偿失。根据局部性的原理来说，其实我们程序跑起来，大部分的其实都是操作在栈上，函数参数啊、函数调用导致的压栈出栈啊、局部变量啊，协程栈，这些如果也弄起写屏障，那么可想而知了，根本就不现实，复杂度和性能就是越不过去的坎。

继续看逃逸什么意思？就是内存分配到堆上。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

先说逃逸分析两点原则：

1. 在保证程序正确性的前提下，尽可能的把对象分配到栈上，这样性能最好；
1. 栈上的对象生命周期就跟随 goroutine ，协程终结了，它就没了
2. 明确一定要分配到堆上对象，或者不确定是否要分配在堆上的对象，那么就全都分配到堆上；
1. 这种对象的生命周期始于业务程序的创建，终于垃圾回收器的回收

我们看到源代码，有四次 new 对象的操作，经过编译器的“逃逸分析”之后，实际分配到堆上的是三次：

1. 14 行 —— 触发逃逸（分配到堆上）
1. 这个必须得分配到堆上，因为除了这个 goroutine 还要存活呢
2. 19 行 —— 无 （分配到栈上）
1. 这个虽然也是 new，单就分配到栈上就行，因为 b0 这个对象就是一个纯粹的栈对象
3. 23 行 —— 触发逃逸 （分配到堆上）
1. 这个需要分配到堆上，因为分配出来的对象需要传递到其他协程使用
4. 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.

所以，从上面简单的汇编代码，我们印证得出几个小知识点：

1. golang 传参和返回参数都是通过栈来传递的（可以思考下优略点，有点是逻辑简单了，也能很好的支持多返回值的实现，缺点是比寄存器的方式略慢，但是这种损耗在程序的运行下可以忽略）；
2. 写屏障是一段编译器插入的特殊代码，在编译期间插入，代码函数名字叫做 gcWriteBarrier ；
3. 屏障代码并不是直接运行，也是要条件判断的，并不是只要是堆上内存赋值就会运行 gcWriteBarrier  代码，而是要有一个条件判断。这里提前透露下，这个条件判断是垃圾回收器扫描开始前，stw 程序给设置上去的；
1. 所以平时对于堆上内存的赋值，多了一次写操作；

伪代码如下：

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 ，这两个寄存器来传参数：

1. rdi ：堆内存写入的地址
2. rax ：赋的值

我们继续看下 runtime·gcWriteBarrier 函数干啥的，这个函数是用纯汇编写的，举一个特定cpu集合的例子，在 asm_amd64.s 里的实现。这个函数只干两件事：

1. 执行写请求
2. 处理 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  flushret:    // 赋值：*slot = val   MOVQ  104(SP), R14  MOVQ  112(SP), R13  MOVQ  AX, (DI)  RETflush:    。。。      //  队列满了，统一处理，这个其实是一个批量优化手段  CALL  runtime·wbBufFlush(SB)    。。。      JMP  ret

思考下：不是说把 *slot = value 直接置灰色，置黑色，就完了嘛，这里搞得这么复杂？

最开始还真不是这样的，这个也是一个优化的过程，这里是利用批量的一个思想做的一个优化。我们再理解下最本质的东西，触发了写屏障之后，我们的核心目的是为了能够把赋值的前后两个值记录下来，以便 GC 垃圾回收器能得到通知，从而避免错误的回收。记录下来是最本质的，但是并不是要立马处理，所以这里做的优化就是，攒满一个 buffer ，然后批量处理，这样效率会非常高的。

wbBuf 结构如下：

|-------------------------------------| 

|  8   |  8   |        8 * 512       | 4 | 

|-------------------------------------|

每个 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()}

所以我们总结下，写屏障到底做了什么：

1. hook 写操作
2. hook 住了写操作之后，把赋值语句的前后两个值都记录下来，投入 buffer 队列
3. 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 函数，这个函数是只有栈操作，非常简单。

下一篇，继续讲述插入写屏障究竟是什么东西？

---

坚持思考，方向比努力更重要。 关注我：奇伢云存储