建站
咨詢
售后
建站咨詢
新聞中心
大家好，我是煎魚。
都江堰網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設(shè)計、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、響應(yīng)式網(wǎng)站開發(fā)等網(wǎng)站項目制作，到程序開發(fā)，運營維護(hù)。創(chuàng)新互聯(lián)建站2013年至今到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)建站。
在 Go 語言中 defer 是一個非常有意思的關(guān)鍵字特性。例子如下：
- package main
- import "fmt"
- func main() {
- defer fmt.Println("煎魚了")
- fmt.Println("腦子進(jìn)")
- }
輸出結(jié)果是：
- 腦子進(jìn)
- 煎魚了
在前幾天我的讀者群內(nèi)有小伙伴討論起了下面這個問題：
讀者群的聊天截圖
簡單來講，問題就是針對在 for 循環(huán)里搞 defer 關(guān)鍵字，是否會造成什么性能影響?
因為在 Go 語言的底層數(shù)據(jù)結(jié)構(gòu)設(shè)計上 defer 是鏈表的數(shù)據(jù)結(jié)構(gòu)：
defer 基本底層結(jié)構(gòu)
大家擔(dān)心如果循環(huán)過大 defer 鏈表會巨長，不夠 “精益求精”。又或是猜想會不會 Go defer 的設(shè)計和 Redis 數(shù)據(jù)結(jié)構(gòu)設(shè)計類似，自己做了優(yōu)化，其實沒啥大影響?
今天這篇文章，我們就來探索循環(huán) Go defer，造成底層鏈表過長會不會帶來什么問題，若有，具體有什么影響?
開始吸魚之路。
defer 性能優(yōu)化 30%
在早年 Go1.13 時曾經(jīng)對 defer 進(jìn)行了一輪性能優(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
- ...
該字段用于標(biāo)識這個 _defer 是在堆上，還是在棧上進(jì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(程序計數(shù)器)，這塊在前文 《深入理解 Go defer》 有詳細(xì)介紹過，這里就不再贅述了。
這個 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 編譯器會根據(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)鍵字，是否會造成什么性能影響?”
最直接的影響就是這大約 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("腦子進(jìn)煎魚了")
- }()
- }
- }
這個也是最常見的模式，無論是寫爬蟲時，又或是 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)鍵字有時候甚至?xí)涣袨榇a規(guī)范不給使用，主要是會造成一些濫用，所以大多數(shù)就選擇其實方式實現(xiàn)邏輯。
這屬于隱式的調(diào)用，造成了類循環(huán)的作用。
總結(jié)
顯然，Defer 在設(shè)計上并沒有說做的特別的奇妙。他主要是根據(jù)實際的一些應(yīng)用場景進(jìn)行了優(yōu)化，達(dá)到了較好的性能。
雖然本身 defer 會帶一點點開銷，但并沒有想象中那么的不堪使用。除非你 defer 所在的代碼是需要頻繁執(zhí)行的代碼，才需要考慮去做優(yōu)化。
否則沒有必要過度糾結(jié)，在實際上，猜測或遇到性能問題時，看看 PProf 的分析，看看 defer 是不是在相應(yīng)的 hot path 之中，再進(jìn)行合理優(yōu)化就好。
所謂的優(yōu)化，可能也只是去掉 defer 而采用手動執(zhí)行，并不復(fù)雜。在編碼時避免踩到 defer 的顯式和隱式循環(huán)這 2 個雷區(qū)就可以達(dá)到性能最大化了。
分享名稱：使用Godefer要小心這2個雷區(qū)！
URL標(biāo)題：http://www.dlmjj.cn/article/dpoedcg.html
