使用Go defer要小心这2个雷区！

大家好，我是煎鱼。

在 Go 语言中 defer 是一个非常有意思的关键字特性。例子如下：

1. package main 
2.  
3. import "fmt" 
4.  
5. func main() { 
6.  defer fmt.Println("煎鱼了") 
7.  
8.  fmt.Println("脑子进") 
9. } 

输出结果是：

1. 脑子进 
2. 煎鱼了 

在前几天我的读者群内有小伙伴讨论起了下面这个问题：

读者群的聊天截图

简单来讲，问题就是针对在 for 循环里搞 defer 关键字，是否会造成什么性能影响?

因为在 Go 语言的底层数据结构设计上 defer 是链表的数据结构：

defer 基本底层结构

大家担心如果循环过大 defer 链表会巨长，不够 “精益求精”。又或是猜想会不会 Go defer 的设计和 Redis 数据结构设计类似，自己做了优化，其实没啥大影响?

今天这篇文章，我们就来探索循环 Go defer，造成底层链表过长会不会带来什么问题，若有，具体有什么影响?

开始吸鱼之路。

defer 性能优化 30%

在早年 Go1.13 时曾经对 defer 进行了一轮性能优化，在大部分场景下 提高了 defer 30% 的性能：

Go defer 1.13 优化记录

我们来回顾一下 Go1.13 的变更，看看 Go defer 优化在了哪里，这是问题的关键点。

以前和现在对比

在 Go1.12 及以前，调用 Go defer 时汇编代码如下：

1. 0x0070 00112 (main.go:6)    CALL    runtime.deferproc(SB) 
2.  0x0075 00117 (main.go:6)    TESTL    AX, AX 
3.  0x0077 00119 (main.go:6)    JNE    137 
4.  0x0079 00121 (main.go:7)    XCHGL    AX, AX 
5.  0x007a 00122 (main.go:7)    CALL    runtime.deferreturn(SB) 
6.  0x007f 00127 (main.go:7)    MOVQ    56(SP), BP 

在 Go1.13 及以后，调用 Go defer 时汇编代码如下：

1. 0x006e 00110 (main.go:4) MOVQ AX, (SP) 
2. 0x0072 00114 (main.go:4) CALL runtime.deferprocStack(SB) 
3. 0x0077 00119 (main.go:4) TESTL AX, AX 
4. 0x0079 00121 (main.go:4) JNE 139 
5. 0x007b 00123 (main.go:7) XCHGL AX, AX 
6. 0x007c 00124 (main.go:7) CALL runtime.deferreturn(SB) 
7. 0x0081 00129 (main.go:7) MOVQ 112(SP), BP 

从汇编的角度来看，像是原本调用 runtime.deferproc 方法改成了调用 runtime.deferprocStack 方法，难道是做了什么优化?

我们抱着疑问继续看下去。

defer 最小单元：_defer

相较于以前的版本，Go defer 的最小单元 _defer 结构体主要是新增了 heap 字段：

1. type _defer struct { 
2.  siz     int32 
3.  siz     int32 // includes both arguments and results 
4.  started bool 
5.  heap    bool 
6.  sp      uintptr // sp at time of defer 
7.  pc      uintptr 
8.  fn      *funcval 
9.  ... 

该字段用于标识这个 _defer 是在堆上，还是在栈上进行分配，其余字段并没有明确变更，那我们可以把聚焦点放在 defer 的堆栈分配上了，看看是做了什么事。

deferprocStack

1. func deferprocStack(d *_defer) { 
2.  gp := getg() 
3.  if gp.m.curg != gp { 
4.   throw("defer on system stack") 
5.  } 
6.   
7.  d.started = false 
8.  d.heap = false 
9.  d.sp = getcallersp() 
10.  d.pc = getcallerpc() 
11.  
12.  *(*uintptr)(unsafe.Pointer(&d._panic)) = 0 
13.  *(*uintptr)(unsafe.Pointer(&d.link)) = uintptr(unsafe.Pointer(gp._defer)) 
14.  *(*uintptr)(unsafe.Pointer(&gp._defer)) = uintptr(unsafe.Pointer(d)) 
15.  
16.  return0() 
17. } 

这一块代码挺常规的，主要是获取调用 defer 函数的函数栈指针、传入函数的参数具体地址以及PC(程序计数器)，这块在前文 《深入理解 Go defer》 有详细介绍过，这里就不再赘述了。

这个 deferprocStack 特殊在哪呢?

可以看到它把 d.heap 设置为了 false，也就是代表 deferprocStack 方法是针对将 _defer 分配在栈上的应用场景的。

deferproc

问题来了，它又在哪里处理分配到堆上的应用场景呢?

1. func newdefer(siz int32) *_defer { 
2.  ... 
3.  d.heap = true 
4.  d.link = gp._defer 
5.  gp._defer = d 
6.  return d 
7. } 

具体的 newdefer 是在哪里调用的呢，如下：

1. func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn 
2.  ... 
3.  sp := getcallersp() 
4.  argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn) 
5.  callerpc := getcallerpc() 
6.  
7.  d := newdefer(siz) 
8.  ... 
9. } 

非常明确，先前的版本中调用的 deferproc 方法，现在被用于对应分配到堆上的场景了。

小结

• 可以确定的是 deferproc 并没有被去掉，而是流程被优化了。
• Go 编译器会根据应用场景去选择使用 deferproc 还是 deferprocStack 方法，他们分别是针对分配在堆上和栈上的使用场景。

优化在哪儿

主要优化在于其 defer 对象的堆栈分配规则的改变，措施是：编译器对 defer 的 for-loop 迭代深度进行分析。

1. // src/cmd/compile/internal/gc/esc.go 
2. case ODEFER: 
3.  if e.loopdepth == 1 { // top level 
4.   n.Esc = EscNever // force stack allocation of defer record (see ssa.go) 
5.   break 
6.  } 

如果 Go 编译器检测到循环深度(loopdepth)为 1，则设置逃逸分析的结果，将分配到栈上，否则分配到堆上。

1. // src/cmd/compile/internal/gc/ssa.go 
2. case ODEFER: 
3.  d := callDefer 
4.  if n.Esc == EscNever { 
5.   d = callDeferStack 
6.  } 
7.  s.call(n.Left, d) 

以此免去了以前频繁调用 systemstack、mallocgc 等方法所带来的大量性能开销，来达到大部分场景提高性能的作用。

循环调用 defer

回到问题本身，知道了 defer 优化的原理后。那 “循环里搞 defer 关键字，是否会造成什么性能影响?”

最直接的影响就是这大约 30% 的性能优化直接全无，且由于姿势不正确，理论上 defer 既有的开销(链表变长)也变大，性能变差。

因此我们要避免以下两种场景的代码：

• 显式循环：在调用 defer 关键字的外层有显式的循环调用，例如：for-loop 语句等。
• 隐式循环：在调用 defer 关键字有类似循环嵌套的逻辑，例如：goto 语句等。

显式循环

第一个例子是直接在代码的 for 循环中使用 defer 关键字：

1. func main() { 
2.  for i := 0; i <= 99; i++ { 
3.   defer func() { 
4.    fmt.Println("脑子进煎鱼了") 
5.   }() 
6.  } 
7. } 

这个也是最常见的模式，无论是写爬虫时，又或是 Goroutine 调用时，不少人都喜欢这么写。

这属于显式的调用了循环。

隐式循环

第二个例子是在代码中使用类似 goto 关键字：

1. func main() { 
2.  i := 1 
3. food: 
4.  defer func() {}() 
5.  if i == 1 { 
6.   i -= 1 
7.   goto food 
8.  } 
9. } 

这种写法比较少见，因为 goto 关键字有时候甚至会被列为代码规范不给使用，主要是会造成一些滥用，所以大多数就选择其实方式实现逻辑。

这属于隐式的调用，造成了类循环的作用。

总结

显然，Defer 在设计上并没有说做的特别的奇妙。他主要是根据实际的一些应用场景进行了优化，达到了较好的性能。

虽然本身 defer 会带一点点开销，但并没有想象中那么的不堪使用。除非你 defer 所在的代码是需要频繁执行的代码，才需要考虑去做优化。

否则没有必要过度纠结，在实际上，猜测或遇到性能问题时，看看 PProf 的分析，看看 defer 是不是在相应的 hot path 之中，再进行合理优化就好。

所谓的优化，可能也只是去掉 defer 而采用手动执行，并不复杂。在编码时避免踩到 defer 的显式和隐式循环这 2 个雷区就可以达到性能最大化了。

原文地址：https://mp.weixin.qq.com/s/ZEsWa4xUb0a7tWemVZMXVw