defer ist eine sehr interessante Schlüsselwortfunktion in der Go-Sprache. Das Beispiel lautet wie folgt:
package main
import "fmt"
func main() {
defer fmt.Println("煎鱼了")
fmt.Println("脑子进")
}Das Ausgabeergebnis ist:
脑子进 煎鱼了
Vor ein paar Tagen diskutierten einige Freunde in meiner Lesergruppe das folgende Problem:
Einfach ausgedrückt handelt es sich bei dem -Problem um den for Hat die Verwendung des Schlüsselworts „defer“ in der Schleife irgendwelche Auswirkungen auf die Leistung? 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
Jeder ist besorgt, dass bei einer zu großen Schleife die verkettete Liste riesig und nicht „ausgezeichnet“ genug sein wird. Oder fragen Sie sich, ob das Design von Go defer dem Design der Redis-Datenstruktur ähnelt und ich es selbst optimiert habe, es aber tatsächlich keine großen Auswirkungen hat? Im heutigen Artikel werden wir die Schleife „Go defer“ untersuchen. Wird es Probleme verursachen, wenn die zugrunde liegende verknüpfte Liste zu lang ist? Beginnen Sie die Reise, Fische anzulocken. 🎜🎜Defer-Leistungsoptimierung um 30 %🎜🎜In den Anfangsjahren von Go1.13 führten wir eine Runde der Leistungsoptimierung bei Defer durch, die die Defer-Leistung in den meisten Szenarien um 30 % verbesserte: 🎜🎜
🎜🎜Sehen wir uns die Änderungen an. Go1 .13 , schau dir an Wo ist die Verzögerungsoptimierung? Dies ist der Kernpunkt des Problems. 🎜Vergleich zwischen vorher und jetzt
🎜In Go1.12 und früher lautet der Assembler-Code beim Aufruf von Go defer wie folgt: 🎜func main() {
for i := 0; i 🎜In Go1.13 und höher lautet der Assembler-Code beim Aufruf von Go defer wie folgt: 🎜<pre class="brush:php;toolbar:false">func main() {
i := 1
food:
defer func() {}()
if i == 1 {
i -= 1
goto food
}
}runtime.deferproc in den Aufruf der Methode runtime.deferprocStack geändert . Könnte es sein, dass einige Optimierungen vorgenommen wurden? 🎜🎜Wir🎜lesen mit Zweifeln weiter. 🎜Defer-Mindesteinheit: _defer
🎜Im Vergleich zu früheren Versionen fügt die Struktur der Mindesteinheit_defer von Go defer hauptsächlich ein neues heap-Feld hinzu: 🎜rrreee🎜Dies Das Feld wird verwendet, um zu identifizieren, ob dieser _defer auf dem Heap oder dem Stapel zugewiesen ist. Die anderen Felder wurden nicht eindeutig geändert, sodass wir uns auf defer ist zugewiesen, um zu sehen, was getan wird. 🎜<h3 id="deferprocStack">deferprocStack</h3>rrreee🎜Dieser Code ist recht konventionell und dient hauptsächlich dazu, den Funktionsstapelzeiger zum Aufrufen der Funktion <code>defer und die spezifische Adresse der an die Funktion übergebenen Parameter zu erhalten. und der PC (Programmzähler). Dies wurde im vorherigen Artikel „Detailliertes Verständnis von Go Defer“ ausführlich vorgestellt, daher werde ich hier nicht näher darauf eingehen. 🎜🎜Was ist das Besondere an diesem deferprocStack? 🎜🎜Sie können sehen, dass d.heap auf false gesetzt wird, was bedeutet, dass die Methode deferprocStack zum Festlegen von _defer dient. Code > Anwendungsszenarien auf dem Stapel zugeordnet. 🎜<h3 id="deferproc">deferproc</h3>🎜Die Frage ist, wo werden Anwendungsszenarien verarbeitet, die dem Heap zugewiesen sind? 🎜rrreee🎜Der spezifische <code>newdefer ist dort, wo er aufgerufen wird, wie folgt: 🎜rrreee🎜Es ist sehr klar, dass die in der vorherigen Version aufgerufene deferproc-Methode jetzt zum Korrespondieren verwendet wird Zuordnung Hier kommt die Szene auf den Stapel. 🎜Zusammenfassung
- Sicher ist, dass
deferprocnicht entfernt, sondern der Prozess optimiert wurde. - Der Go-Compiler wählt die Methode
deferprocoderdeferprocStackentsprechend dem Anwendungsszenario Haufen und auf dem Stapel.
Der
für <code des compilers>defer -loop Iteriert tiefgreifend durch die Analyse. 🎜rrreee🎜Wenn der Go-Compiler erkennt, dass die Schleifentiefe (Loop Depth) 1 ist, wird das Ergebnis der Escape-Analyse festgelegt und auf dem Stapel zugewiesen, andernfalls wird es auf dem Heap zugewiesen. 🎜rrreee🎜Dadurch entfällt der große Leistungsaufwand, der in der Vergangenheit durch häufige Aufrufe von systemstack, mallocgc und anderen Methoden verursacht wurde, wodurch die Leistung in den meisten Szenarien verbessert wird. 🎜🎜Anrufverzögerung in einer Schleife🎜🎜Zurück zum Problem selbst, nachdem wir das Prinzip der Verzögerungsoptimierung kennengelernt haben. Dann: „Hat das Schlüsselwort „defer“ in der Schleife irgendwelche Auswirkungen auf die Leistung? wird ebenfalls größer und die Leistung wird schlechter. 🎜🎜Deshalb wollen wir Code für die folgenden zwei Szenarien vermeiden: 🎜- 显式循环：在调用 defer 关键字的外层有显式的循环调用，例如：
for-loop语句等。 - 隐式循环：在调用 defer 关键字有类似循环嵌套的逻辑，例如：
goto语句等。
显式循环
第一个例子是直接在代码的 for 循环中使用 defer 关键字：
func main() {
for i := 0; i <p>这个也是最常见的模式，无论是写爬虫时，又或是 Goroutine 调用时，不少人都喜欢这么写。</p><p>这属于显式的调用了循环。</p><h3 id="隐式循环">隐式循环</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教程栏目！
