Go defer 會有性能損耗，盡量不要用？

wangshijun 發布于2019-07-01 14:00 / 770人閱讀

摘要：原文地址會有性能損耗，盡量不要用上個月在軒脈刃的全棧技術群里看到一個小伙伴問說在棧退出時執行，會有性能損耗，盡量不要用，這個怎么解。因此，對于會有性能損耗，盡量不能用這個問題，我認為該用就用，應該及時關閉就不要延遲，在用時一定要想清楚場景。

原文地址：Go defer 會有性能損耗，盡量不要用？

上個月在 @polaris @軒脈刃的全棧技術群里看到一個小伙伴問 “說 defer 在棧退出時執行，會有性能損耗，盡量不要用，這個怎么解？”。

恰好前段時間寫了一篇《深入理解 Go defer》去詳細剖析 defer 關鍵字。那么這一次簡單結合前文對這個問題進行探討一波，希望對你有所幫助，但在此之前希望你花幾分鐘，自己思考一下答案，再繼續往下看。

測試

func DoDefer(key, value string) {
    defer func(key, value string) {
        _ = key + value
    }(key, value)
}

func DoNotDefer(key, value string) {
    _ = key + value
}

基準測試：

func BenchmarkDoDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        DoDefer("煎魚", "https://github.com/EDDYCJY/blog")
    }
}

func BenchmarkDoNotDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        DoNotDefer("煎魚", "https://github.com/EDDYCJY/blog")
    }
}

輸出結果：

$ go test -bench=. -benchmem -run=none
goos: darwin
goarch: amd64
pkg: github.com/EDDYCJY/awesomeDefer
BenchmarkDoDefer-4          20000000            91.4 ns/op          48 B/op           1 allocs/op
BenchmarkDoNotDefer-4       30000000            41.6 ns/op          48 B/op           1 allocs/op
PASS
ok      github.com/EDDYCJY/awesomeDefer    3.234s

從結果上來，使用 defer 后的函數開銷確實比沒使用高了不少，這損耗用到哪里去了呢？

想一下

$ go tool compile -S main.go 
"".main STEXT size=163 args=0x0 locals=0x40
    ...
    0x0059 00089 (main.go:6)    MOVQ    AX, 16(SP)
    0x005e 00094 (main.go:6)    MOVQ    $1, 24(SP)
    0x0067 00103 (main.go:6)    MOVQ    $1, 32(SP)
    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
    0x0084 00132 (main.go:7)    ADDQ    $64, SP
    0x0088 00136 (main.go:7)    RET
    0x0089 00137 (main.go:6)    XCHGL    AX, AX
    0x008a 00138 (main.go:6)    CALL    runtime.deferreturn(SB)
    0x008f 00143 (main.go:6)    MOVQ    56(SP), BP
    0x0094 00148 (main.go:6)    ADDQ    $64, SP
    0x0098 00152 (main.go:6)    RET
    ...

我們在前文提到 defer 關鍵字其實涉及了一系列的連鎖調用，內部 runtime 函數的調用就至少多了三步，分別是 runtime.deferproc 一次和 runtime.deferreturn 兩次。

而這還只是在運行時的顯式動作，另外編譯器做的事也不少，例如：

在 deferproc 階段（注冊延遲調用），還得獲取/傳入目標函數地址、函數參數等等。

在 deferreturn 階段，需要在函數調用結尾處插入該方法的調用，同時若有被 defer 的函數，還需要使用 runtime·jmpdefer 進行跳轉以便于后續調用。

這一些動作途中還要涉及最小單元 _defer 的獲取/生成， defer 和 recover 鏈表的邏輯處理和消耗等動作。

Q&A

最后討論的時候有提到 “問題指的是本來就是用來執行 close() 一些操作的，然后說盡量不能用，例子就把 defer db.close() 前面的 defer 刪去了” 這個疑問。

這是一個比較類似 “教科書” 式的說法，在一些入門教程中會潛移默化的告訴你在資源控制后加個 defer 延遲關閉一下。例如：

resp, err := http.Get(...)
if err != nil {
    return err
}
defer resp.Body.Close()

但是一定得這么寫嗎？其實并不，很多人給出的理由都是 “怕你忘記” 這種說辭，這沒有毛病。但需要認清場景，假設我的應用場景如下：

resp, err := http.Get(...)
if err != nil {
    return err
}
defer resp.Body.Close()
// do something
time.Sleep(time.Second * 60)

嗯，一個請求當然沒問題，流量、并發一下子大了呢，那可能就是個災難了。你想想為什么？從常見的 defer + close 的使用組合來講，用之前建議先看清楚應用場景，在保證無異常的情況下確保盡早關閉才是首選。如果只是小范圍調用很快就返回的話，偷個懶直接一套組合拳出去也未嘗不可。

結論

一個 defer 關鍵字實際上包含了不少的動作和處理，和你單純調用一個函數一條指令是沒法比的。而與對照物相比，它確確實實是有性能損耗，目前延遲調用的全部開銷大約在 50ns，但 defer 所提供的作用遠遠大于此，你從全局來看，它的損耗非常小，并且官方還不斷地在優化中。

因此，對于 “Go defer 會有性能損耗，盡量不能用？” 這個問題，我認為該用就用，應該及時關閉就不要延遲，在 hot paths 用時一定要想清楚場景。

補充

補充上柴大的回復：“不是性能問題，defer 最大的功能是 Panic 后依然有效。如果沒有 defer，Panic 后就會導致 unlock 丟失，從而導致死鎖了”，非常經典。

GPU云服務器云服務器不要用損耗最低 go 部署用的服務器 deference

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/31733.html

jQuery 3.0 beta 發布

摘要：回調函數將固定為異步執行。這些將被移除這些應該會保留需要注意的是，那些繼續存在的回調函數不會有任何變化，只有的方法會受影響。創作不夠，譯文來湊。跟上篇一樣是編譯，不準備逐字翻。比如，我會把we譯成jQuery官方團隊，或者他們。初譯版，待校正。這篇文章比較長，翻譯難度也不小，如果有問題，歡迎提出，我盡量修改。正文開始。歪果仁也要雙喜臨門，于是 jQuery 官方團隊選在 j...

LeanCloud 2019-08-22 10:59 評論0 收藏0
后端好書閱讀與推薦（續四）

摘要：后端好書閱讀與推薦系列文章后端好書閱讀與推薦后端好書閱讀與推薦續后端好書閱讀與推薦續二后端好書閱讀與推薦續三后端好書閱讀與推薦續四這里依然記錄一下每本書的亮點與自己讀書心得和體會，分享并求拍磚。后端好書閱讀與推薦系列文章：后端好書閱讀與推薦后端好書閱讀與推薦（續）后端好書閱讀與推薦（續二）后端好書閱讀與推薦（續三）后端好書閱讀與推薦（續四）這里依然記錄一下每本書的亮點與自己讀書心得...

phodal 2019-06-28 17:55 評論0 收藏0
前端頁面卡頓、也許是DOM操作惹的禍？

摘要：界面上的更改都是通過操作實現的，并不是通過傳統的刷新頁面實現的。操作優化的總原則是盡量減少操作。通過在文檔片段上進行操作，可以降低操作對頁面性能的影響，這種方式是創建一個文檔片段，并在此片段上進行必要的操作，操作完成后將它附加在頁面中。界面上UI的更改都是通過DOM操作實現的，并不是通過傳統的刷新頁面實現的。盡管DOM提供了豐富接口供外部調用，但DOM操作的代價很高，頁面前端代碼的...

AnthonyHan 2019-08-20 16:57 評論0 收藏0
《高性能JavaScript》（讀書筆記）

摘要：加載的模塊會以參數形式傳入該函數，從而在回調函數內部就可以使用這些模塊。異步加載，和，瀏覽器不會失去響應它指定的回調函數，只有前面的模塊都加載成功后，才會運行，解決了依賴性的問題。插件，可以讓回調函數在頁面結構加載完成后再運行。這次主要是對《高性能JavaScript》一書的讀書筆記，記錄下自己之前沒有注意到或者需要引起重視的地方第一章加載和執行 js代碼在執行過程中會阻塞瀏覽...

moven_j 2019-08-21 17:58 評論0 收藏0
面試官問你如何解決web高并發這樣回答就好了

摘要：所謂高并發，就是同一時間有很多流量通常指用戶訪問程序的接口頁面及其他資源，解決高并發就是當流量峰值到來時保證程序的穩定性。索引多主多從分布式數據庫緩存連接池消息隊列等是從數據庫方便考慮如何優化性能。所謂高并發，就是同一時間有很多流量(通常指用戶)訪問程序的接口、頁面及其他資源，解決高并發就是當流量峰值到來時保證程序的穩定性。我們一般用QPS(每秒查詢數，又叫每秒請求數)來衡量程序的...

Achilles 2019-07-01 10:54 評論0 收藏0