CFSDN坚持开源创造价值，我们致力于搭建一个资源共享平台，让每一个IT人在这里找到属于你的精彩世界.

这篇CFSDN的博客文章使用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 。

最后此篇关于使用Go defer要小心这2个雷区！的文章就讲到这里了,如果你想了解更多关于使用Go defer要小心这2个雷区！的内容请搜索CFSDN的文章或继续浏览相关文章，希望大家以后支持我的博客！ 。