深入理解 Go defer

https://github.com/EDDYCJY/blog/blob/master/golang/pkg/2019-05-26-Go-defer.md

在上一章节 《深入理解 Go panic and recover》 中,我们发现了 defer 与其关联性极大,还是觉得非常有必要深入一下。希望通过本章节大家可以对 defer 关键字有一个深刻的理解,那么我们开始吧。你先等等,请排好队,我们这儿采取后进先出 LIFO 的出站方式…

特性

我们简单的过一下 defer 关键字的基础使用,让大家先有一个基础的认知

一、延迟调用

  1. func main() {
  2. defer log.Println("EDDYCJY.")
  3. log.Println("end.")
  4. }

输出结果:

  1. $ go run main.go
  2. 2019/05/19 21:15:02 end.
  3. 2019/05/19 21:15:02 EDDYCJY.

二、后进先出

  1. func main() {
  2. for i := 0; i < 6; i++ {
  3. defer log.Println("EDDYCJY" + strconv.Itoa(i) + ".")
  4. }
  5. log.Println("end.")
  6. }

输出结果:

  1. $ go run main.go
  2. 2019/05/19 21:19:17 end.
  3. 2019/05/19 21:19:17 EDDYCJY5.
  4. 2019/05/19 21:19:17 EDDYCJY4.
  5. 2019/05/19 21:19:17 EDDYCJY3.
  6. 2019/05/19 21:19:17 EDDYCJY2.
  7. 2019/05/19 21:19:17 EDDYCJY1.
  8. 2019/05/19 21:19:17 EDDYCJY0.

三、运行时间点

  1. func main() {
  2. func() {
  3. defer log.Println("defer.EDDYCJY.")
  4. }()
  5. log.Println("main.EDDYCJY.")
  6. }

输出结果:

  1. $ go run main.go
  2. 2019/05/22 23:30:27 defer.EDDYCJY.
  3. 2019/05/22 23:30:27 main.EDDYCJY.

四、异常处理

  1. func main() {
  2. defer func() {
  3. if e := recover(); e != nil {
  4. log.Println("EDDYCJY.")
  5. }
  6. }()
  7. panic("end.")
  8. }

输出结果:

  1. $ go run main.go
  2. 2019/05/20 22:22:57 EDDYCJY.

源码剖析

  1. $ go tool compile -S main.go
  2. "".main STEXT size=163 args=0x0 locals=0x40
  3. ...
  4. 0x0059 00089 (main.go:6) MOVQ AX, 16(SP)
  5. 0x005e 00094 (main.go:6) MOVQ $1, 24(SP)
  6. 0x0067 00103 (main.go:6) MOVQ $1, 32(SP)
  7. 0x0070 00112 (main.go:6) CALL runtime.deferproc(SB)
  8. 0x0075 00117 (main.go:6) TESTL AX, AX
  9. 0x0077 00119 (main.go:6) JNE 137
  10. 0x0079 00121 (main.go:7) XCHGL AX, AX
  11. 0x007a 00122 (main.go:7) CALL runtime.deferreturn(SB)
  12. 0x007f 00127 (main.go:7) MOVQ 56(SP), BP
  13. 0x0084 00132 (main.go:7) ADDQ $64, SP
  14. 0x0088 00136 (main.go:7) RET
  15. 0x0089 00137 (main.go:6) XCHGL AX, AX
  16. 0x008a 00138 (main.go:6) CALL runtime.deferreturn(SB)
  17. 0x008f 00143 (main.go:6) MOVQ 56(SP), BP
  18. 0x0094 00148 (main.go:6) ADDQ $64, SP
  19. 0x0098 00152 (main.go:6) RET
  20. ...

首先我们需要找到它,找到它实际对应什么执行代码。通过汇编代码,可得知涉及如下方法:

  • runtime.deferproc
  • runtime.deferreturn

很显然是运行时的方法,是对的人。我们继续往下走看看都分别承担了什么行为

数据结构

在开始前我们需要先介绍一下 defer 的基础单元 _defer 结构体,如下:

  1. type _defer struct {
  2. siz int32
  3. started bool
  4. sp uintptr // sp at time of defer
  5. pc uintptr
  6. fn *funcval
  7. _panic *_panic // panic that is running defer
  8. link *_defer
  9. }
  10. ...
  11. type funcval struct {
  12. fn uintptr
  13. // variable-size, fn-specific data here
  14. }
  • siz:所有传入参数的总大小
  • started:该 defer 是否已经执行过
  • sp:函数栈指针寄存器,一般指向当前函数栈的栈顶
  • pc:程序计数器,有时称为指令指针(IP),线程利用它来跟踪下一个要执行的指令。在大多数处理器中,PC指向的是下一条指令,而不是当前指令
  • fn:指向传入的函数地址和参数
  • _panic:指向 _panic 链表
  • link:指向 _defer 链表

image

deferproc

  1. func deferproc(siz int32, fn *funcval) {
  2. ...
  3. sp := getcallersp()
  4. argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
  5. callerpc := getcallerpc()
  6. d := newdefer(siz)
  7. ...
  8. d.fn = fn
  9. d.pc = callerpc
  10. d.sp = sp
  11. switch siz {
  12. case 0:
  13. // Do nothing.
  14. case sys.PtrSize:
  15. *(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
  16. default:
  17. memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
  18. }
  19. return0()
  20. }
  • 获取调用 defer 函数的函数栈指针、传入函数的参数具体地址以及PC (程序计数器),也就是下一个要执行的指令。这些相当于是预备参数,便于后续的流转控制
  • 创建一个新的 defer 最小单元 _defer,填入先前准备的参数
  • 调用 memmove 将传入的参数存储到新 _defer (当前使用)中去,便于后续的使用
  • 最后调用 return0 进行返回,这个函数非常重要。能够避免在 deferproc 中又因为返回 return,而诱发 deferreturn 方法的调用。其根本原因是一个停止 panic 的延迟方法会使 deferproc 返回 1,但在机制中如果 deferproc 返回不等于 0,将会总是检查返回值并跳转到函数的末尾。而 return0 返回的就是 0,因此可以防止重复调用

小结

这个函数中会为新的 _defer 设置一些基础属性,并将调用函数的参数集传入。最后通过特殊的返回方法结束函数调用。另外这一块与先前 《深入理解 Go panic and recover》 的处理逻辑有一定关联性,其实就是 gp.sched.ret 返回 0 还是 1 会分流至不同处理方式

newdefer

  1. func newdefer(siz int32) *_defer {
  2. var d *_defer
  3. sc := deferclass(uintptr(siz))
  4. gp := getg()
  5. if sc < uintptr(len(p{}.deferpool)) {
  6. pp := gp.m.p.ptr()
  7. if len(pp.deferpool[sc]) == 0 && sched.deferpool[sc] != nil {
  8. ...
  9. lock(&sched.deferlock)
  10. d := sched.deferpool[sc]
  11. unlock(&sched.deferlock)
  12. }
  13. ...
  14. }
  15. if d == nil {
  16. systemstack(func() {
  17. total := roundupsize(totaldefersize(uintptr(siz)))
  18. d = (*_defer)(mallocgc(total, deferType, true))
  19. })
  20. ...
  21. }
  22. d.siz = siz
  23. d.link = gp._defer
  24. gp._defer = d
  25. return d
  26. }
  • 从池中获取可以使用的 _defer,则复用作为新的基础单元
  • 若在池中没有获取到可用的,则调用 mallocgc 重新申请一个新的
  • 设置 defer 的基础属性,最后修改当前 Goroutine_defer 指向

通过这个方法我们可以注意到两点,如下:

  • deferGoroutine(g) 有直接关系,所以讨论 defer 时基本离不开 g 的关联
  • 新的 defer 总是会在现有的链表中的最前面,也就是 defer 的特性后进先出

小结

这个函数主要承担了获取新的 _defer 的作用,它有可能是从 deferpool 中获取的,也有可能是重新申请的

deferreturn

  1. func deferreturn(arg0 uintptr) {
  2. gp := getg()
  3. d := gp._defer
  4. if d == nil {
  5. return
  6. }
  7. sp := getcallersp()
  8. if d.sp != sp {
  9. return
  10. }
  11. switch d.siz {
  12. case 0:
  13. // Do nothing.
  14. case sys.PtrSize:
  15. *(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
  16. default:
  17. memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
  18. }
  19. fn := d.fn
  20. d.fn = nil
  21. gp._defer = d.link
  22. freedefer(d)
  23. jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
  24. }

如果在一个方法中调用过 defer 关键字,那么编译器将会在结尾处插入 deferreturn 方法的调用。而该方法中主要做了如下事项:

  • 清空当前节点 _defer 被调用的函数调用信息
  • 释放当前节点的 _defer 的存储信息并放回池中(便于复用)
  • 跳转到调用 defer 关键字的调用函数处

在这段代码中,跳转方法 jmpdefer 格外重要。因为它显式的控制了流转,代码如下:

  1. // asm_amd64.s
  2. TEXT runtime·jmpdefer(SB), NOSPLIT, $0-16
  3. MOVQ fv+0(FP), DX // fn
  4. MOVQ argp+8(FP), BX // caller sp
  5. LEAQ -8(BX), SP // caller sp after CALL
  6. MOVQ -8(SP), BP // restore BP as if deferreturn returned (harmless if framepointers not in use)
  7. SUBQ $5, (SP) // return to CALL again
  8. MOVQ 0(DX), BX
  9. JMP BX // but first run the deferred function

通过源码的分析,我们发现它做了两个很 “奇怪” 又很重要的事,如下:

  • MOVQ -8(SP), BP:-8(BX) 这个位置保存的是 deferreturn 执行完毕后的地址
  • SUBQ $5, (SP):SP 的地址减 5 ,其减掉的长度就恰好是 runtime.deferreturn 的长度

你可能会问,为什么是 5?好吧。翻了半天最后看了一下汇编代码…嗯,相减的确是 5 没毛病,如下:

  1. 0x007a 00122 (main.go:7) CALL runtime.deferreturn(SB)
  2. 0x007f 00127 (main.go:7) MOVQ 56(SP), BP

我们整理一下思绪,照上述逻辑的话,那 deferreturn 就是一个 “递归” 了哦。每次都会重新回到 deferreturn 函数,那它在什么时候才会结束呢,如下:

  1. func deferreturn(arg0 uintptr) {
  2. gp := getg()
  3. d := gp._defer
  4. if d == nil {
  5. return
  6. }
  7. ...
  8. }

也就是会不断地进入 deferreturn 函数,判断链表中是否还存着 _defer。若已经不存在了,则返回,结束掉它。简单来讲,就是处理完全部 defer 才允许你真的离开它。果真如此吗?我们再看看上面的汇编代码,如下:

  1. 。..
  2. 0x0070 00112 (main.go:6) CALL runtime.deferproc(SB)
  3. 0x0075 00117 (main.go:6) TESTL AX, AX
  4. 0x0077 00119 (main.go:6) JNE 137
  5. 0x0079 00121 (main.go:7) XCHGL AX, AX
  6. 0x007a 00122 (main.go:7) CALL runtime.deferreturn(SB)
  7. 0x007f 00127 (main.go:7) MOVQ 56(SP), BP
  8. 0x0084 00132 (main.go:7) ADDQ $64, SP
  9. 0x0088 00136 (main.go:7) RET
  10. 0x0089 00137 (main.go:6) XCHGL AX, AX
  11. 0x008a 00138 (main.go:6) CALL runtime.deferreturn(SB)
  12. ...

的确如上述流程所分析一致,验证完毕

小结

这个函数主要承担了清空已使用的 defer 和跳转到调用 defer 关键字的函数处,非常重要

总结

我们有提到 defer 关键字涉及两个核心的函数,分别是 deferprocdeferreturn 函数。而 deferreturn 函数比较特殊,是当应用函数调用 defer 关键字时,编译器会在其结尾处插入 deferreturn 的调用,它们俩一般都是成对出现的

但是当一个 Goroutine 上存在着多次 defer 行为(也就是多个 _defer)时,编译器会进行利用一些小技巧, 重新回到 deferreturn 函数去消耗 _defer 链表,直到一个不剩才允许真正的结束

而新增的基础单元 _defer,有可能是被复用的,也有可能是全新申请的。它最后都会被追加到 _defer 链表的表头,从而设定了后进先出的调用特性

关联

参考

ft_authoradmin  ft_create_time2019-06-07 21:36
 ft_update_time2019-06-07 21:37