如何正確使用Go defer

這篇文章主要介紹“如何正確使用Go defer”，在日常操作中，相信很多人在如何正確使用Go defer問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”如何正確使用Go defer”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

在 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 關鍵字有時候甚至會被列為代碼規范不給使用，主要是會造成一些濫用，所以大多數就選擇其實方式實現邏輯。

這屬于隱式的調用，造成了類循環的作用。

到此，關于“如何正確使用Go defer”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！