特性
我们简单的过一下 defer 关键字的基础使用，让大家先有一个基础的认知
一、延迟调用
func main() {
defer log.Println("EDDYCJY.")
log.Println("end.")
}
输出结果：
$ go run main.go
2019/05/19 21:15:02 end.
2019/05/19 21:15:02 EDDYCJY.
二、后进先出
func main() {
for i := 0; i < 6; i++ {
defer log.Println("EDDYCJY" + strconv.Itoa(i) + ".")
}
log.Println("end.")
}
输出结果：
$ go run main.go
2019/05/19 21:19:17 end.
2019/05/19 21:19:17 EDDYCJY5.
2019/05/19 21:19:17 EDDYCJY4.
2019/05/19 21:19:17 EDDYCJY3.
2019/05/19 21:19:17 EDDYCJY2.
2019/05/19 21:19:17 EDDYCJY1.
2019/05/19 21:19:17 EDDYCJY0.
三、运行时间点
func main() {
func() {
defer log.Println("defer.EDDYCJY.")
}()
log.Println("main.EDDYCJY.")
}
输出结果：
$ go run main.go
2019/05/22 23:30:27 defer.EDDYCJY.
2019/05/22 23:30:27 main.EDDYCJY.
四、异常处理
func main() {
defer func() {
if e := recover(); e != nil {
log.Println("EDDYCJY.")
}
}()
panic("end.")
}
输出结果：
$ go run main.go
2019/05/20 22:22:57 EDDYCJY.
源码剖析
$ go tool compile -S main.go
"".main STEXT size=163 args=0x0 locals=0x40
...
0x0059 00089 (main.go:6) MOVQ AX, 16(SP)
0x005e 00094 (main.go:6) MOVQ $1, 24(SP)
0x0067 00103 (main.go:6) MOVQ $1, 32(SP)
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
0x0084 00132 (main.go:7) ADDQ $64, SP
0x0088 00136 (main.go:7) RET
0x0089 00137 (main.go:6) XCHGL AX, AX
0x008a 00138 (main.go:6) CALL runtime.deferreturn(SB)
0x008f 00143 (main.go:6) MOVQ 56(SP), BP
0x0094 00148 (main.go:6) ADDQ $64, SP
0x0098 00152 (main.go:6) RET
...
首先我们需要找到它，找到它实际对应什么执行代码。通过汇编代码，可得知涉及如下方法：
runtime.deferprocruntime.deferreturn
很显然是运行时的方法，是对的。我们继续往下走看看都分别承担了什么行为
数据结构
在开始前我们需要先介绍一下 defer 的基础单元 _defer 结构体，如下：
type _defer struct {
siz int32
started bool
sp uintptr // sp at time of defer
pc uintptr
fn *funcval
_panic *_panic // panic that is running defer
link *_defer
}
...
type funcval struct {
fn uintptr
// variable-size, fn-specific data here
}
- siz：所有传入参数的总大小
- started：该
defer是否已经执行过 - sp：函数栈指针寄存器，一般指向当前函数栈的栈顶
- pc：程序计数器，有时称为指令指针(IP)，线程利用它来跟踪下一个要执行的指令。在大多数处理器中，PC 指向的是下一条指令，而不是当前指令
- fn：指向传入的函数地址和参数
- _panic：指向
_panic链表 - link：指向
_defer链表
deferproc，预处理defer函数，存储到结构中，供后面调用
func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
//获取当前goroutuine
gp := getg()
if gp.m.curg != gp {
// go code on the system stack can't defer
throw("defer on system stack")
}
// the arguments of fn are in a perilous state. The stack map
// for deferproc does not describe them. So we can't let garbage
// collection or stack copying trigger until we've copied them out
// to somewhere safe. The memmove below does that.
// Until the copy completes, we can only call nosplit routines.
//上层函数的sp
sp := getcallersp()
//函数参数的地址获取
argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)
//当前函数的pc
callerpc := getcallerpc()
//获取p中的缓存结构,复用，减少内存分配
d := newdefer(siz)
if d._panic != nil {
throw("deferproc: d.panic != nil after newdefer")
}
//此处将defer结构指向g中已经存储的defer，并且赋值给当前的g，目的就是defer的先进后出
d.link = gp._defer
gp._defer = d
d.fn = fn
d.pc = callerpc
d.sp = sp
switch siz {
case 0:
// Do nothing.
case sys.PtrSize:
//指针，直接把defer末尾地址指针指向参数指针指向的内容
*(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))
default:
//非指针，把参数移植到defer末尾
memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))
}
// deferproc returns 0 normally.
// a deferred func that stops a panic
// makes the deferproc return 1.
// the code the compiler generates always
// checks the return value and jumps to the
// end of the function if deferproc returns != 0.
return0()
// No code can go here - the C return register has
// been set and must not be clobbered.
}
- 获取调用
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
func newdefer(siz int32) *_defer {
var d *_defer
sc := deferclass(uintptr(siz))
gp := getg()
if sc < uintptr(len(p{}.deferpool)) {
pp := gp.m.p.ptr()
if len(pp.deferpool[sc]) == 0 && sched.deferpool[sc] != nil {
...
lock(&sched.deferlock)
d := sched.deferpool[sc]
unlock(&sched.deferlock)
}
...
}
if d == nil {
systemstack(func() {
total := roundupsize(totaldefersize(uintptr(siz)))
d = (*_defer)(mallocgc(total, deferType, true))
})
...
}
d.siz = siz
d.link = gp._defer
gp._defer = d
return d
}
- 从池中获取可以使用的
_defer，则复用作为新的基础单元 - 若在池中没有获取到可用的，则调用
mallocgc重新申请一个新的 - 设置
defer的基础属性，最后修改当前Goroutine的_defer指向
通过这个方法我们可以注意到两点，如下：
defer与Goroutine(g)有直接关系，所以讨论defer时基本离不开g的关联- 新的
defer总是会在现有的链表中的最前面，也就是defer的特性后进先出
小结
这个函数主要承担了获取新的 _defer 的作用，它有可能是从 deferpool 中获取的，也有可能是重新申请的
deferreturn
func deferreturn(arg0 uintptr) {
gp := getg()
d := gp._defer
if d == nil {
return
}
sp := getcallersp()
if d.sp != sp {
return
}
switch d.siz {
case 0:
// Do nothing.
case sys.PtrSize:
*(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))
default:
memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))
}
fn := d.fn
d.fn = nil
//g的链表下一个，指向下一个defer
gp._defer = d.link
//此处清空defer，放回对象池
freedefer(d)
//
jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}
如果在一个方法中调用过 defer 关键字，那么编译器将会在结尾处插入 deferreturn 方法的调用。而该方法中主要做了如下事项：
- 清空当前节点
_defer被调用的函数调用信息 - 释放当前节点的
_defer的存储信息并放回池中（便于复用） - 跳转到调用
defer关键字的调用函数处
在这段代码中，跳转方法 jmpdefer 格外重要。因为它显式的控制了流转，代码如下：
// asm_amd64.s
TEXT runtime·jmpdefer(SB), NOSPLIT, $0-16
MOVQ fv+0(FP), DX // fn
MOVQ argp+8(FP), BX // caller sp
LEAQ -8(BX), SP // caller sp after CALL
MOVQ -8(SP), BP // restore BP as if deferreturn returned (harmless if framepointers not in use)
SUBQ $5, (SP) // return to CALL again
MOVQ 0(DX), BX
JMP BX // but first run the deferred function
通过源码的分析，我们发现它做了两个很 “奇怪” 又很重要的事，如下：
- MOVQ -8(SP), BP：
-8(BX)这个位置保存的是deferreturn执行完毕后的地址 - SUBQ $5, (SP)：
SP的地址减 5 ，其减掉的长度就恰好是runtime.deferreturn的长度
你可能会问，为什么是 5？好吧。翻了半天最后看了一下汇编代码…嗯，相减的确是 5 没毛病，如下：
0x007a 00122 (main.go:7) CALL runtime.deferreturn(SB)
0x007f 00127 (main.go:7) MOVQ 56(SP), BP
我们整理一下思绪，照上述逻辑的话，那 deferreturn 就是一个 “递归” 了哦。每次都会重新回到 deferreturn 函数，那它在什么时候才会结束呢，如下：
func deferreturn(arg0 uintptr) {
gp := getg()
d := gp._defer
if d == nil {
return
}
...
}
也就是会不断地进入 deferreturn 函数，判断链表中是否还存着 _defer。若已经不存在了，则返回，结束掉它。简单来讲，就是处理完全部 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
0x0084 00132 (main.go:7) ADDQ $64, SP
0x0088 00136 (main.go:7) RET
0x0089 00137 (main.go:6) XCHGL AX, AX
0x008a 00138 (main.go:6) CALL runtime.deferreturn(SB)
...
的确如上述流程所分析一致，验证完毕
小结
这个函数主要承担了清空已使用的 defer 和跳转到调用 defer 关键字的函数处，非常重要
总结
我们有提到 defer 关键字涉及两个核心的函数，分别是 deferproc 和 deferreturn 函数。而 deferreturn 函数比较特殊，是当应用函数调用 defer 关键字时，编译器会在其结尾处插入 deferreturn 的调用，它们俩一般都是成对出现的
但是当一个 Goroutine 上存在着多次 defer 行为（也就是多个 _defer）时，编译器会进行利用一些小技巧， 重新回到 deferreturn 函数去消耗 _defer 链表，直到一个不剩才允许真正的结束
而新增的基础单元 _defer，有可能是被复用的，也有可能是全新申请的。它最后都会被追加到 _defer 链表的表头，从而设定了后进先出的调用特性
有疑问加站长微信联系（非本文作者）
