使用Go defer時要注意什么

本篇內容介紹了“使用Go defer時要注意什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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

package main

import "fmt"

func main() {
    defer fmt.Println("煎魚了")

    fmt.Println("腦子進")
}

輸出結果是：

腦子進
煎魚了

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

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

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

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

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

開始吸魚之路。

defer 性能優化 30%

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

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

“使用Go defer時要注意什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！