共计 3784 个字符，预计需要花费 10 分钟才能阅读完成。
微信搜寻【脑子进煎鱼了】关注这一只爆肝煎鱼。本文 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，造成底层链表过长会不会带来什么问题，若有，具体有什么影响？
开始吸鱼之路。
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.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 对象的堆栈调配规定的扭转，措施是：
编译器对 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 优化的原理后。那“循环里搞 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 催更。