如何正確使用Godefer

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

創(chuàng)新互聯(lián)主營山陽網(wǎng)站建設的網(wǎng)絡公司,主營網(wǎng)站建設方案,app軟件開發(fā)公司,山陽h5微信小程序開發(fā)搭建,山陽網(wǎng)站營銷推廣歡迎山陽等地區(qū)企業(yè)咨詢

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

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

輸出結(jié)果是：

腦子進 煎魚了

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

讀者群的聊天截圖

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

因為在 Go 語言的底層數(shù)據(jù)結(jié)構(gòu)設計上 defer 是鏈表的數(shù)據(jù)結(jié)構(gòu)：

defer 基本底層結(jié)構(gòu)

大家擔心如果循環(huán)過大 defer 鏈表會巨長，不夠 “精益求精”。又或是猜想會不會 Go defer 的設計和 redis 數(shù)據(jù)結(jié)構(gòu)設計類似，自己做了優(yōu)化，其實沒啥大影響?

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

開始吸魚之路。

defer 性能優(yōu)化 30%

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

Go defer 1.13 優(yōu)化記錄

我們來回顧一下 Go1.13 的變更，看看 Go defer 優(yōu)化在了哪里，這是問題的關(guān)鍵點。

以前和現(xiàn)在對比

在 Go1.12 及以前，調(diào)用 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 及以后，調(diào)用 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

從匯編的角度來看，像是原本調(diào)用 runtime.deferproc 方法改成了調(diào)用 runtime.deferprocStack  方法，難道是做了什么優(yōu)化?

我們抱著疑問繼續(xù)看下去。

defer 最小單元：_defer

相較于以前的版本，Go defer 的最小單元 _defer 結(jié)構(gòu)體主要是新增了 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() }

這一塊代碼挺常規(guī)的，主要是獲取調(diào)用 defer 函數(shù)的函數(shù)棧指針、傳入函數(shù)的參數(shù)具體地址以及PC(程序計數(shù)器)，這塊在前文 《深入理解 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 是在哪里調(diào)用的呢，如下：

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)  ... }

非常明確，先前的版本中調(diào)用的 deferproc 方法，現(xiàn)在被用于對應分配到堆上的場景了。

小結(jié)

• 可以確定的是 deferproc 并沒有被去掉，而是流程被優(yōu)化了。

• Go 編譯器會根據(jù)應用場景去選擇使用 deferproc 還是 deferprocStack 方法，他們分別是針對分配在堆上和棧上的使用場景。

優(yōu)化在哪兒

主要優(yōu)化在于其 defer 對象的堆棧分配規(guī)則的改變，措施是：編譯器對 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 編譯器檢測到循環(huán)深度(loopdepth)為 1，則設置逃逸分析的結(jié)果，將分配到棧上，否則分配到堆上。

// src/cmd/compile/internal/gc/ssa.go case ODEFER:  d := callDefer  if n.Esc == EscNever {   d = callDeferStack  }  s.call(n.Left, d)

以此免去了以前頻繁調(diào)用 systemstack、mallocgc 等方法所帶來的大量性能開銷，來達到大部分場景提高性能的作用。

循環(huán)調(diào)用 defer

回到問題本身，知道了 defer 優(yōu)化的原理后。那 “循環(huán)里搞 defer 關(guān)鍵字，是否會造成什么性能影響?”

最直接的影響就是這大約 30% 的性能優(yōu)化直接全無，且由于姿勢不正確，理論上 defer 既有的開銷(鏈表變長)也變大，性能變差。

因此我們要避免以下兩種場景的代碼：

• 顯式循環(huán)：在調(diào)用 defer 關(guān)鍵字的外層有顯式的循環(huán)調(diào)用，例如：for-loop 語句等。

• 隱式循環(huán)：在調(diào)用 defer 關(guān)鍵字有類似循環(huán)嵌套的邏輯，例如：goto 語句等。

顯式循環(huán)

第一個例子是直接在代碼的 for 循環(huán)中使用 defer 關(guān)鍵字：

func main() {  for i := 0; i <= 99; i++ {   defer func() {    fmt.Println("腦子進煎魚了")   }()  } }

這個也是最常見的模式，無論是寫爬蟲時，又或是 Goroutine 調(diào)用時，不少人都喜歡這么寫。

這屬于顯式的調(diào)用了循環(huán)。

隱式循環(huán)

第二個例子是在代碼中使用類似 goto 關(guān)鍵字：

func main() {  i := 1 food:  defer func() {}()  if i == 1 {   i -= 1   goto food  } }

這種寫法比較少見，因為 goto 關(guān)鍵字有時候甚至會被列為代碼規(guī)范不給使用，主要是會造成一些濫用，所以大多數(shù)就選擇其實方式實現(xiàn)邏輯。

這屬于隱式的調(diào)用，造成了類循環(huán)的作用。

到此，關(guān)于“如何正確使用Go defer”的學習就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
網(wǎng)站標題：如何正確使用Godefer
文章路徑：http://m.jiaotiyi.com/article/ipoesc.html