[[395204]]

大家好，我是煎魚。

在 Go 語言中 defer 是一個非常有意思的關鍵字特性。例子如下：

package main 
 
import "fmt" 
 
func main() { 
 defer fmt.Println("煎魚了") 
 
 fmt.Println("腦子進") 
} 

輸出結果是：

腦子進 
煎魚了 

在前幾天我的讀者群內有小伙伴討論起了下面這個問題：

讀者群的聊天截圖

簡單來講，問題就是針對在 for 循環里搞 defer 關鍵字，是否會造成什么性能影響?

因為在 Go 語言的底層數據結構設計上 defer 是鏈表的數據結構：

defer 基本底層結構

大家擔心如果循環過大 defer 鏈表會巨長，不夠 “精益求精”。又或是猜想會不會 Go defer 的設計和 Redis 數據結構設計類似，自己做了優化，其實沒啥大影響?

今天這篇文章，我們就來探索循環 Go defer，造成底層鏈表過長會不會帶來什么問題，若有，具體有什么影響?

開始吸魚之路。

defer 性能優化 30%

在早年 Go1.13 時曾經對 defer 進行了一輪性能優化，在大部分場景下 提高了 defer 30% 的性能：

Go defer 1.13 優化記錄

我們來回顧一下 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 個雷區就可以達到性能最大化了。