defer est une fonctionnalité de mots-clés très intéressante en langage Go. L'exemple est le suivant :
package main
import "fmt"
func main() {
defer fmt.Println("煎鱼了")
fmt.Println("脑子进")
}
Le résultat de sortie est :
脑子进 煎鱼了
Il y a quelques jours, des amis de mon groupe de lecteurs ont discuté du problème suivant :
Pour faire simple, le problème concerne le for L'utilisation du mot-clé defer dans la boucle entraînera-t-elle un impact sur les performances ? 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
Tout le monde craint que si la boucle est trop grande, la liste des liens de report sera énorme et pas assez "excellente". Ou vous demandez-vous si la conception de Go defer est similaire à la conception de la structure de données Redis, et je l'ai optimisée moi-même, mais cela n'a en réalité pas beaucoup d'impact ? Dans l'article d'aujourd'hui, nous explorerons la boucle Go defer. Cela posera-t-il des problèmes si la liste chaînée sous-jacente est trop longue ? Si oui, quels sont les impacts spécifiques ? Commencez le voyage pour attirer les poissons. 🎜🎜optimisation des performances du report de 30 %🎜🎜Dans les premières années de Go1.13, nous avons mené une série d'optimisation des performances sur le report, qui a amélioré les performances du report de 30 % dans la plupart des scénarios : 🎜🎜
🎜🎜Revoyons les changements dans Go1 .13 , regarde Aller Où le report est-il optimisé ? C'est le point clé du problème. 🎜Comparaison entre avant et maintenant
🎜Dans Go1.12 et avant, le code assembleur lors de l'appel de Go defer est le suivant : 🎜func main() {
for i := 0; i 🎜Dans Go1.13 et versions ultérieures, le code assembleur lors de l'appel de Go defer est comme suit : 🎜<pre class="brush:php;toolbar:false">func main() {
i := 1
food:
defer func() {}()
if i == 1 {
i -= 1
goto food
}
}🎜Du point de vue de l'assembleur, par exemple, l'appel d'origine à la méthode runtime.deferproc a été remplacé par l'appel à la méthode runtime.deferprocStack . Se pourrait-il qu'une certaine optimisation ait été effectuée ? 🎜🎜Nous🎜continuons à lire avec des doutes. 🎜Defer minimum unit: _defer
🎜Par rapport aux versions précédentes, la structure_defer de l'unité minimale de Go defer ajoute principalement un nouveau champ heap：🎜rrreee🎜Ceci Le champ est utilisé pour identifier si ce _defer est alloué sur le tas ou sur la pile. Les autres champs n'ont pas été clairement modifiés, on peut donc se concentrer sur defer est. alloué pour voir ce qui est fait. 🎜<h3>deferprocStack</h3>rrreee🎜Ce morceau de code est assez classique, principalement pour obtenir le pointeur de pile de fonctions pour appeler la fonction <code>defer, l'adresse spécifique des paramètres passés dans la fonction, et le PC (compteur de programme). Cela a été présenté en détail dans l'article précédent "Compréhension approfondie de Go Defer", je n'entrerai donc pas dans les détails ici. 🎜🎜Quelle est la particularité de ce deferprocStack ? 🎜🎜Vous pouvez voir qu'il définit d.heap sur false, ce qui signifie que la méthode deferprocStack sert à définir _defer code > Scénarios d’application alloués sur la pile. 🎜<h3>deferproc</h3>🎜La question est : où gère-t-il les scénarios d'application alloués sur le tas ? 🎜rrreee🎜Le <code>newdefer spécifique est l'endroit où il est appelé, comme suit : 🎜rrreee🎜Il est très clair que la méthode deferproc appelée dans la version précédente est désormais utilisée pour correspondre allocation Voici la scène sur la pile. 🎜Résumé
- Ce qui est sûr c'est que
deferprocn'a pas été supprimé, mais le processus a été optimisé. - Le compilateur Go choisira d'utiliser la méthode
deferprocoudeferprocStackselon le scénario d'application. Elles sont respectivement destinées au scénario d'utilisation d'allocation sur le. tas et sur la pile.
Le
for du <code.>defer</code.> -loop Itère profondément à travers l'analyse. 🎜rrreee🎜Si le compilateur Go détecte que la profondeur de boucle (loopdegree) est de 1, il définit le résultat de l'analyse d'échappement et sera alloué sur la pile, sinon il sera alloué sur le tas. 🎜rrreee🎜Cela élimine l'importante surcharge de performances causée par les appels fréquents à systemstack, mallocgc et à d'autres méthodes dans le passé, améliorant ainsi les performances dans la plupart des scénarios. 🎜🎜Call Defer en boucle🎜🎜Retour au problème lui-même, après avoir connu le principe de l'optimisation du report. Ensuite, "Le mot-clé defer dans la boucle aura-t-il un impact sur les performances ?" L'impact le plus direct est qu'environ 30 % de l'optimisation des performances est complètement perdue et, en raison d'une posture incorrecte, la surcharge existante du defer (la liste chaînée devient plus longue) devient également plus grand et les performances se détériorent. 🎜🎜Nous voulons donc éviter le code pour les deux scénarios suivants : 🎜- 显式循环：在调用 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教程栏目！