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

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

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

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

輸出結(jié)果是：

腦子進(jìn) 煎魚了

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

讀者群的聊天截圖

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

因?yàn)樵?Go 語言的底層數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)上 defer 是鏈表的數(shù)據(jù)結(jié)構(gòu)：

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

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

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

開始吸魚之路。

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

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

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

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

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

在 Go1.12 及以前，調(diào)用 Go defer 時(shí)匯編代碼如下：

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 時(shí)匯編代碼如下：

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

該字段用于標(biāo)識這個(gè) _defer 是在堆上，還是在棧上進(jìn)行分配，其余字段并沒有明確變更，那我們可以把聚焦點(diǎn)放在 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(程序計(jì)數(shù)器)，這塊在前文 《深入理解 Go defer》  有詳細(xì)介紹過，這里就不再贅述了。

這個(gè) deferprocStack 特殊在哪呢?

可以看到它把 d.heap 設(shè)置為了 false，也就是代表 deferprocStack 方法是針對將 _defer 分配在棧上的應(yīng)用場景的。

deferproc

問題來了，它又在哪里處理分配到堆上的應(yīng)用場景呢?

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)在被用于對應(yīng)分配到堆上的場景了。

小結(jié)

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

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

優(yōu)化在哪兒

主要優(yōu)化在于其 defer 對象的堆棧分配規(guī)則的改變，措施是：編譯器對 defer 的 for-loop 迭代深度進(jìn)行分析。

// 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，則設(shè)置逃逸分析的結(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 等方法所帶來的大量性能開銷，來達(dá)到大部分場景提高性能的作用。

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

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

最直接的影響就是這大約 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)

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

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

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

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

隱式循環(huán)

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

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

這種寫法比較少見，因?yàn)?goto 關(guān)鍵字有時(shí)候甚至?xí)涣袨榇a規(guī)范不給使用，主要是會(huì)造成一些濫用，所以大多數(shù)就選擇其實(shí)方式實(shí)現(xiàn)邏輯。

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

到此，關(guān)于“如何正確使用Go defer”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！

新聞名稱：如何正確使用Godefer
本文來源：http://aaarwkj.com/article32/ipoesc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、App開發(fā)、品牌網(wǎng)站設(shè)計(jì)、標(biāo)簽優(yōu)化、自適應(yīng)網(wǎng)站、移動(dòng)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)