defer는 Go 언어의 매우 흥미로운 키워드 기능입니다. 예는 다음과 같습니다.
package main
import "fmt"
func main() {
defer fmt.Println("煎鱼了")
fmt.Println("脑子进")
}
출력 결과는 다음과 같습니다.
脑子进 煎鱼了
며칠 전 독자 그룹의 일부 친구들이 다음 문제에 대해 논의했습니다.
간단히 말하면 문제는 에 관한 것입니다. for 루프에서 defer 키워드를 사용하면 성능에 영향을 미치나요? 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
루프가 너무 크면 지연 연결 목록이 거대해지고 충분히 "우수"하지 않을 것이라고 모두가 걱정합니다. 아니면 Go defer의 디자인이 Redis의 데이터 구조 디자인과 유사하고, 제가 직접 최적화했지만 실제로는 큰 영향이 없는지 궁금하신가요? 오늘 기사에서는 Go defer 루프를 살펴보겠습니다. 기본 연결 목록이 너무 길면 문제가 발생합니까? 그렇다면 구체적인 영향은 무엇입니까? 물고기 유인 여행을 시작해보세요. 🎜🎜30% 연기 성능 최적화🎜🎜Go1.13 초기에 우리는 연기에 대한 일련의 성능 최적화를 수행하여 대부분의 시나리오에서 연기 성능을 30% 향상시켰습니다. 🎜🎜
🎜🎜Go1의 변경 사항을 검토해 보겠습니다. .13 , 보세요 가세요 defer는 어디에 최적화되어 있나요? 이것이 문제의 핵심입니다. 🎜이전과 현재 비교
🎜Go1.12 이전에서 Go defer 호출 시 어셈블리 코드는 다음과 같습니다. 🎜func main() {
for i := 0; i 🎜Go1.13 이상에서는 Go defer 호출 시 어셈블리 코드는 다음과 같습니다. 🎜<pre class="brush:php;toolbar:false">func main() {
i := 1
food:
defer func() {}()
if i == 1 {
i -= 1
goto food
}
}🎜From 예를 들어 어셈블리 관점에서 runtime.deferproc 메서드에 대한 원래 호출이 runtime.deferprocStack 메서드에 대한 호출로 변경되었습니다. .. 어느 정도 최적화가 이루어진 것이 아닐까요? 🎜🎜우리🎜의심스러운 마음으로 계속 읽어보세요. 🎜최소 단위 연기: _defer
🎜이전 버전과 비교하여 Go defer의 최소 단위_defer 구조는 주로 새로운 힙 필드를 추가합니다. ：🎜rrreee🎜이것은 필드는 이 _defer가 힙에 할당되었는지 스택에 할당되었는지 식별하는 데 사용됩니다. 다른 필드는 명확하게 변경되지 않았으므로 defer의 스택은 수행된 작업을 확인하도록 할당되었습니다. 🎜<h3>deferprocStack</h3>rrreee🎜이 코드 조각은 주로 <code>defer 함수를 호출하기 위한 함수 스택 포인터, 함수에 전달된 매개변수의 특정 주소, 그리고 PC(프로그램 카운터)에 대해서는 이전 글 "Go Defer에 대한 심층적인 이해"에서 자세히 소개했기 때문에 여기서는 자세히 다루지 않겠습니다. 🎜🎜이 deferprocStack의 특별한 점은 무엇인가요? 🎜🎜d.heap을 false로 설정한 것을 볼 수 있습니다. 이는 deferprocStack 메서드가 _defer를 설정하기 위한 것임을 의미합니다. 코드 > 스택에 할당된 애플리케이션 시나리오. 🎜<h3>deferproc</h3>🎜문제는 힙에 할당된 애플리케이션 시나리오를 어디에서 처리하느냐는 것입니다. 🎜rrreee🎜특정 <code>newdefer가 호출되는 위치는 다음과 같습니다. 🎜rrreee🎜이전 버전에서 호출된 deferproc 메소드가 이제 해당 작업에 사용된다는 것이 매우 명확해졌습니다. 할당 여기에 더미 장면이 있습니다. 🎜요약
- 확실한 것은
deferproc가 제거되지 않았지만 프로세스가 최적화되었다는 것입니다. - Go 컴파일러는 애플리케이션 시나리오에 따라
deferproc또는deferprocStack메서드를 사용하도록 선택합니다. 힙과 스택에 있습니다.
컴파일러의
for <code>defer -loop 분석을 통해 심층적으로 반복합니다. 🎜rrreee🎜Go 컴파일러가 루프 깊이(looplength)가 1임을 감지하면 이스케이프 분석 결과를 설정하여 스택에 할당하고, 그렇지 않으면 힙에 할당합니다. 🎜rrreee🎜이는 과거에 systemstack, mallocgc 및 기타 메서드를 자주 호출하여 발생했던 대규모 성능 오버헤드를 제거하여 대부분의 시나리오에서 성능을 향상시킵니다. 🎜🎜루프에서 지연 호출🎜🎜최적화 지연의 원리를 알고 나면 문제 자체로 돌아가세요. 그러면 "루프의 defer 키워드가 성능에 영향을 미칠까요?" 가장 직접적인 영향은 성능 최적화의 약 30%가 완전히 손실되고 잘못된 자세로 인해 이론적으로 기존 defer 오버헤드(연결된 목록이 길어짐)가 발생한다는 것입니다. 크기도 커지고 성능도 나빠집니다. 🎜🎜그래서 우리는 다음 두 가지 시나리오에 대한 코드를 피하고 싶습니다. 🎜- 显式循环：在调用 defer 关键字的外层有显式的循环调用，例如：
for-loop语句等。 - 隐式循环：在调用 defer 关键字有类似循环嵌套的逻辑，例如：
goto语句等。
显式循环
第一个例子是直接在代码的 for 循环中使用 defer 关键字：
func main() {
for i := 0; i <p>这个也是最常见的模式，无论是写爬虫时，又或是 Goroutine 调用时，不少人都喜欢这么写。</p><p>这属于显式的调用了循环。</p><h3>隐式循环</h3><p>第二个例子是在代码中使用类似 <code>goto</code> 关键字：</p><pre class="brush:php;toolbar:false">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教程栏目！