关于php:使用-Go-defer-要小心这-2-个折腾人的雷区

微信搜寻【脑子进煎鱼了】关注这一只爆肝煎鱼。本文 GitHub github.com/eddycjy/blog 已收录，有我的系列文章、材料和开源 Go 图书。

大家好，我是煎鱼。

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

package main

import "fmt"

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

    fmt.Println("脑子进")
}

输入后果是：

脑子进
煎鱼了

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

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

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

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

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

开始吸鱼之路。

在早年 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.deferproc 办法改成了调用 runtime.deferprocStack 办法，难道是做了什么优化？

咱们 抱着疑难 持续看上来。

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

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
    ...

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

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 函数的函数栈指针、传入函数的参数具体地址以及 PC（程序计数器），这块在前文《深刻了解 Go defer》有具体介绍过，这里就不再赘述了。

这个 deferprocStack 非凡在哪呢？

能够看到它把 d.heap 设置为了 false，也就是代表 deferprocStack 办法是针对将 _defer 调配在栈上的利用场景的。

问题来了，它又在哪里解决调配到堆上的利用场景呢？

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 办法，当初被用于对应调配到堆上的场景了。

能够确定的是 deferproc 并没有被去掉，而是流程被优化了。
Go 编译器会依据利用场景去抉择应用 deferproc 还是 deferprocStack 办法，他们别离是针对调配在堆上和栈上的应用场景。

次要优化在于其 defer 对象的堆栈调配规定的扭转，措施是：
编译器对 defer 的 for-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)

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

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

最间接的影响就是这大概 30% 的性能优化间接全无，且因为姿态不正确，实践上 defer 既有的开销（链表变长）也变大，性能变差。

因而咱们要防止以下两种场景的代码：

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

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

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 个雷区就能够达到性能最大化了。

若有任何疑难欢送评论区反馈和交换，最好的关系是相互成就 ，各位的点赞就是煎鱼创作的最大能源，感激反对。

文章继续更新，能够微信搜【脑子进煎鱼了】浏览，回复【000】有我筹备的一线大厂面试算法题解和材料；本文 GitHub github.com/eddycjy/blog 已收录，欢送 Star 催更。

关于php:使用-Go-defer-要小心这-2-个折腾人的雷区

defer 性能优化 30%

以前和当初比照

defer 最小单元：_defer

deferprocStack

deferproc

小结

优化在哪儿

循环调用 defer

显式循环

隐式循环

总结