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

package main

import "fmt"

func main() {
    defer fmt.Println("煎鱼了")

    fmt.Println("脑子进")
}

输出结果是：

脑子进
煎鱼了

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

for

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

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

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

开始吸鱼之路。

defer 性能优化 30%

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

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

以前和现在对比

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

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

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

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

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

defer 最小单元：_defer

_deferheap
type _defer struct {
    siz     int32
    siz     int32 // includes both arguments and results
    started bool
    heap    bool
    sp      uintptr // sp at time of defer
    pc      uintptr
    fn      *funcval
    ...
_deferdefer

deferprocStack

func deferprocStack(d *_defer) {
    gp := getg()
    if gp.m.curg != gp {
        throw("defer on system stack")
    }
    
    d.started = false
    d.heap = false
    d.sp = getcallersp()
    d.pc = getcallerpc()

    *(*uintptr)(unsafe.Pointer(&d._panic)) = 0
    *(*uintptr)(unsafe.Pointer(&d.link)) = uintptr(unsafe.Pointer(gp._defer))
    *(*uintptr)(unsafe.Pointer(&gp._defer)) = uintptr(unsafe.Pointer(d))

    return0()
}
defer
deferprocStack
d.heapfalsedeferprocStack_defer

deferproc

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

func newdefer(siz int32) *_defer {
    ...
    d.heap = true
    d.link = gp._defer
    gp._defer = d
    return d
}
newdefer
func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
    ...
    sp := getcallersp()
    argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
    callerpc := getcallerpc()

    d := newdefer(siz)
    ...
}
deferproc

小结

deferprocdeferprocdeferprocStack

优化在哪儿

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

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

// src/cmd/compile/internal/gc/ssa.go
case ODEFER:
    d := callDefer
    if n.Esc == EscNever {
        d = callDeferStack
    }
    s.call(n.Left, d)
systemstackmallocgc

循环调用 defer

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

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

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

for-loopgoto

显式循环

for
func main() {
    for i := 0; i <= 99; i++ {
        defer func() {
            fmt.Println("脑子进煎鱼了")
        }()
    }
}

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

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

隐式循环

goto
func main() {
    i := 1
food:
    defer func() {}()
    if i == 1 {
        i -= 1
        goto food
    }
}
goto

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

总结

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

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

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

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