• 技术文章 >后端开发 >Golang

    使用Go defer时要注意这两处!

    藏色散人藏色散人2021-07-10 15:09:28转载128

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

    package main
    
    import "fmt"
    
    func main() {
        defer fmt.Println("煎鱼了")
    
        fmt.Println("脑子进")
    }

    输出结果是:

    脑子进
    煎鱼了

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

    e86912e2c39a2a5fdec4297582317c1.png

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

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

    edbecff899547b64be32cc899631d16.png

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

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

    开始吸鱼之路。

    defer 性能优化 30%

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

    c8a14d4859d227f43e9b9abaa8ef720.png

    我们来回顾一下 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 方法,难道是做了什么优化?

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

    defer 最小单元:_defer

    相较于以前的版本,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 的堆栈分配上了,看看是做了什么事。

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

    这个 deferprocStack 特殊在哪呢?

    可以看到它把 d.heap 设置为了 false,也就是代表 deferprocStack 方法是针对将 _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 方法,现在被用于对应分配到堆上的场景了。

    小结

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

    优化在哪儿

    主要优化在于其 defer 对象的堆栈分配规则的改变,措施是:
    编译器对 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 既有的开销(链表变长)也变大,性能变差。

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

    • 显式循环:在调用 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 个雷区就可以达到性能最大化了。

    更多golang相关技术文章,请访问golang教程栏目!

    以上就是使用Go defer时要注意这两处!的详细内容,更多请关注php中文网其它相关文章!

    声明:本文转载于:segmentfault,如有侵犯,请联系admin@php.cn删除
    专题推荐:golang
    上一篇:分享Golang中一个好用的viper配置模块 下一篇:有没有发现Go 1.17将允许切片转换为数组指针啦?
    第16期线上培训班

    相关文章推荐

    • 什么是Golang中的interface• 关于Golang Slice的append扩容• golang看什么书• 解析golang iris怎么使用

    全部评论我要评论

  • 取消发布评论发送
  • 1/1

    PHP中文网