defer 的前世今生
延遲語句 defer 在最早期的 Go 語言設計中并不存在，后來才單獨增加了這一特性，由 Robert Griesemer 完成語言規范的編寫 [Griesemer, 2009]， 并由 Ken Thompson 完成最早期的實現 [Thompson, 2009]，兩人合作完成這一語言特性。
defer 的語義表明，它會在函數返回、產生恐慌或者 runtime.Goexit 時被調用。直覺上看，defer 應該由編譯器直接將需要的函數調用插入到該調用的地方，似乎是一個編譯期特性，不應該存在運行時性能問題，非常類似于 C++ 的 RAII 范式（當離開資源的作用域時，自動執行析構函數）。但實際情況是，由于 defer 并沒有與其依賴資源掛鉤，也允許在條件、循環語句中出現，從而不再是一個作用域相關的概念，這就是使得 defer 的語義變得相對復雜。在一些復雜情況下，無法在編譯期決定存在多少個 defer 調用。
例如，在一個執行次數不確定的 for 循環中，defer 的執行次數是隨機的：
func randomDefers() {rand.Seed(time.Now().UnixNano())for rand.Intn(100) > 42 {defer func() {println("changkun.de/golang")}()} }因而 defer 并不是免費的午餐，在一個復雜的調用中，當無法直接確定需要的產生的延遲調用的數量時，延遲語句將導致運行性能的下降。本文我們來討論 defer 的實現本質及其對癥下藥的相關性能優化手段。
defer 的類型
在堆上分配的 defer
編譯階段
運行階段
在棧上創建 defer
開放編碼式 defer
產生條件
延遲比特
defer 的優化之路
小結
進一步閱讀的參考文獻
defer 的類型
延遲語句的文法產生式 DeferStmt -> "defer" Expression 的描述非常的簡單，因而也很容易將其處理為語法樹的形式，但我們這里更關心的其實是它語義背后的中間和目標代碼的形式。
在 《Go 語言原本》Go 程序編譯流程 一節中我們提到過，在進行中間代碼生成階段，會通過 compileSSA 先調用 buildssa 為函數體生成 SSA 形式的函數，而后調用 genssa 將函數的 SSA 中間表示轉換為具體的指令。
Go 語言的語句在執行 buildssa 階段中，會由 state.stmt 完成函數中各個語句的 SSA 處理。
// src/cmd/compile/internal/gc/ssa.go func buildssa(fn *Node, worker int) *ssa.Func {var s state...s.stmtList(fn.Nbody)... } func (s *state) stmtList(l Nodes) {for _, n := range l.Slice() { s.stmt(n) } }對于延遲語句而言，其中間表示會產生三種不同的延遲形式， 第一種是最一般情況下的在堆上分配的延遲語句，第二種是允許在棧上分配的延遲語句，最后一種則是**開放編碼式（Open-coded）**的延遲語句。
// src/cmd/compile/internal/gc/ssa.go func (s *state) stmt(n *Node) {...switch n.Op {case ODEFER:// 開放編碼式 deferif s.hasOpenDefers {s.openDeferRecord(n.Left)} else {// 堆上分配的 deferd := callDeferif n.Esc == EscNever {// 棧上分配的 deferd = callDeferStack}s.call(n.Left, d)}case ...}... }在堆上分配的 defer
我們先來討論最簡單的在堆上分配的 defer 這種形式。在堆上分配的原因是 defer 語句出現在了循環語句里，或者無法執行更高階的編譯器優化導致的。
如果一個與 defer 出現在循環語句中，則可執行的次數可能無法在編譯期決定；如果一個調用中 defer 由于數量過多等原因，不能被編譯器進行開放編碼，則也會在堆上分配 defer。
總之，由于這種不確定性的存在，在堆上分配的 defer 需要最多的運行時支持，因而產生的運行時開銷也最大。
編譯階段
為了使延遲語句的功能滿足語言規范，該語句在編譯的 SSA 階段會被翻譯為兩個主體，其中第一個主體是被延遲的函數本身，另一個主體則是函數結束時需要執行所記錄 defer 的代碼塊。
state.call 調用會生成用于記錄延遲調用參數的指令，并創建一個 deferproc 的調用指令；而后 state.exit 調用在函數返回前插入 deferreturn 調用的指令。
// src/cmd/compile/internal/gc/ssa.go func (s *state) call(n *Node, k callKind) *ssa.Value {...var call *ssa.Valueif k == callDeferStack {...} else {// 在堆上創建 deferargStart := Ctxt.FixedFrameSize()// Defer 參數if k != callNormal {// 記錄 deferproc 的參數argsize := s.constInt32(types.Types[TUINT32], int32(stksize))addr := s.constOffPtrSP(s.f.Config.Types.UInt32Ptr, argStart)s.store(types.Types[TUINT32], addr, argsize) // 保存參數大小 sizaddr = s.constOffPtrSP(s.f.Config.Types.UintptrPtr, argStart+int64(Widthptr))s.store(types.Types[TUINTPTR], addr, closure) // 保存函數地址 fnstksize += 2 * int64(Widthptr)argStart += 2 * int64(Widthptr)}...// 創建 deferproc 調用switch {case k == callDefer:call = s.newValue1A(ssa.OpStaticCall, types.TypeMem, deferproc, s.mem())...}...}...// 結束 defer 塊if k == callDefer || k == callDeferStack {s.exit()...}... } func (s *state) exit() *ssa.Block {if s.hasdefer {if s.hasOpenDefers {...} else {// 調用 deferreturns.rtcall(Deferreturn, true, nil)}}... }例如，對于一個純粹的 defer 調用而言：
package mainfunc foo() {return }func main() {defer foo()return }如果我們將其強制編譯為在堆上分配的形式，可以觀察到如下的匯編代碼。其中 defer foo()被轉化為了 deferproc 調用，并在函數返回前，調用了 deferreturn：
TEXT main.foo(SB) /Users/changkun/Desktop/defer/ssa/main.goreturn0x104ea20 c3 RET TEXT main.main(SB) /Users/changkun/Desktop/defer/ssa/main.go func main() {...// 將 defer foo() { ... }() 轉化為一個 deferproc 調用// 在調用 deferproc 前完成參數的準備工作，這個例子中沒有參數0x104ea4d c7042400000000 MOVL $0x0, 0(SP) 0x104ea54 488d0585290200 LEAQ go.func.*+60(SB), AX 0x104ea5b 4889442408 MOVQ AX, 0x8(SP) 0x104ea60 e8bb31fdff CALL runtime.deferproc(SB) ...// 函數返回指令 RET 前插入的 deferreturn 語句0x104ea7b 90 NOPL 0x104ea7c e82f3afdff CALL runtime.deferreturn(SB) 0x104ea81 488b6c2410 MOVQ 0x10(SP), BP 0x104ea86 4883c418 ADDQ $0x18, SP 0x104ea8a c3 RET // 函數的尾聲0x104ea8b e8d084ffff CALL runtime.morestack_noctxt(SB) 0x104ea90 eb9e JMP main.main(SB)運行階段
一個函數中的延遲語句會被保存為一個 _defer 記錄的鏈表，附著在一個 Goroutine 上。_defer 記錄的具體結構也非常簡單，主要包含了參與調用的參數大小、當前 defer 語句所在函數的 PC 和 SP 寄存器、被 defer 的函數的入口地址以及串聯多個 defer 的 link 鏈表，該鏈表指向下一個需要執行的 defer，如圖 9.2.1 所示。
// src/runtime/panic.go type _defer struct {siz int32heap boolsp uintptrpc uintptrfn *funcvallink *_defer... } // src/runtime/runtime2.go type g struct {..._defer *_defer... }附著在 Goroutine 上的 _defer 記錄的鏈表
現在我們知道，一個在堆上分配的延遲語句被編譯為了 deferproc，用于記錄被延遲的函數調用；在函數的尾聲，會插入 deferreturn 調用，用于執行被延遲的調用。
下面我們就來詳細看看這兩個調用具體發生了什么事情。
我們先看創建 defer 的第一種形式 deferproc。這個調用很簡單，僅僅只是將需要被 defer 調用的函數做了一次記錄：
//go:nosplit func deferproc(siz int32, fn *funcval) {...sp := getcallersp()argp := uintptr(unsafe.Pointer(&fn)) + unsafe.Sizeof(fn)callerpc := getcallerpc()d := newdefer(siz)d.fn = fnd.pc = callerpcd.sp = sp// 將參數保存到 _defer 記錄中switch siz {case 0: // 什么也不做case sys.PtrSize:*(*uintptr)(deferArgs(d)) = *(*uintptr)(unsafe.Pointer(argp))default:memmove(deferArgs(d), unsafe.Pointer(argp), uintptr(siz))}return0() }這段代碼中，本質上只是在做一些簡單參數處理，比如 fn 保存了 defer 所調用函數的調用地址，siz 確定了其參數的大小。并且通過 newdefer 來創建一個新的 _defer 實例，然后由 fn、callerpc 和 sp 來保存調用該 defer 的 Goroutine 上下文。
注意，在這里我們看到了一個對參數進行拷貝的操作。這個操作也是我們在實踐過程中經歷過的，defer 調用被記錄時，并不會對參數進行求值，而是會對參數完成一次拷貝。這么做原因是由于語義上的考慮。直覺上講，defer 的參數應當在它所寫的位置對傳入的參數進行求值，而不是將求值步驟推遲，因為延后的參數可能發生變化，導致 defer 的語義發生意料之外的錯誤。
例如，f, _ := os.Open("file.txt") 后立刻指定 defer f.Close()，倘若隨后的語句修改了 f 的值，那么將導致 f 無法被正常關閉。
出于性能考慮，newdefer 通過 P 或者調度器 sched 上的本地或全局 defer 池來復用已經在堆上分配的內存。defer 的資源池會根據被延遲的調用所需的參數來決定 defer 記錄的大小等級，每 16 個字節分一個等級。此做法的動機與運行時內存分配器針對不同大小對象的分配思路雷同，這里不再做深入討論。
// src/runtime/runtime2.go type p struct {...// 不同大小的本地 defer 池deferpool [5][]*_deferdeferpoolbuf [5][32]*_defer... } type schedt struct {...// 不同大小的全局 defer 池deferlock mutexdeferpool [5]*_defer... }對于新建的 _defer 實例而言，會將其加入到 Goroutine 所保留的 defer 鏈表上，通過 link 字段串聯。
// src/runtime/panic.go//go:nosplit func newdefer(siz int32) *_defer {var d *_defersc := deferclass(uintptr(siz))gp := getg()// 檢查 defer 參數的大小是否從 p 的 deferpool 直接分配if sc < uintptr(len(p{}.deferpool)) {pp := gp.m.p.ptr()// 如果 p 本地無法分配，則從全局池中獲取一半 defer，來填充 P 的本地資源池if len(pp.deferpool[sc]) == 0 && sched.deferpool[sc] != nil {// 出于性能考慮，如果發生棧的增長，則會調用 morestack，// 進一步降低 defer 的性能。因此切換到系統棧上執行，進而不會發生棧的增長。systemstack(func() {lock(&sched.deferlock)for len(pp.deferpool[sc]) < cap(pp.deferpool[sc])/2 && sched.deferpool[sc] != nil {d := sched.deferpool[sc]sched.deferpool[sc] = d.linkd.link = nilpp.deferpool[sc] = append(pp.deferpool[sc], d)}unlock(&sched.deferlock)})}// 從 P 本地進行分配if n := len(pp.deferpool[sc]); n > 0 {d = pp.deferpool[sc][n-1]pp.deferpool[sc][n-1] = nilpp.deferpool[sc] = pp.deferpool[sc][:n-1]}}// 沒有可用的緩存，直接從堆上分配新的 defer 和 argsif d == nil {systemstack(func() {total := roundupsize(totaldefersize(uintptr(siz)))d = (*_defer)(mallocgc(total, deferType, true))})}// 將 _defer 實例添加到 Goroutine 的 _defer 鏈表上。d.siz = sizd.heap = trued.link = gp._defergp._defer = dreturn d }deferreturn 被編譯器插入到函數末尾，當跳轉到它時，會將需要被 defer 的入口地址取出，然后跳轉并執行：
// src/runtime/panic.go//go:nosplit func deferreturn(arg0 uintptr) {gp := getg()d := gp._deferif d == nil {return}// 確定 defer 的調用方是不是當前 deferreturn 的調用方sp := getcallersp()if d.sp != sp {return}...// 將參數復制出 _defer 記錄外switch d.siz {case 0: // 什么也不做case sys.PtrSize:*(*uintptr)(unsafe.Pointer(&arg0)) = *(*uintptr)(deferArgs(d))default:memmove(unsafe.Pointer(&arg0), deferArgs(d), uintptr(d.siz))}// 獲得被延遲的調用 fn 的入口地址，并隨后立即將 _defer 釋放掉fn := d.fnd.fn = nilgp._defer = d.linkfreedefer(d)// 調用，并跳轉到下一個 deferjmpdefer(fn, uintptr(unsafe.Pointer(&arg0))) }在這個函數中，會在需要時對 defer 的參數再次進行拷貝，多個 defer 函數以 jmpdefer 尾調用形式被實現。在跳轉到 fn 之前，_defer 實例被釋放歸還，jmpdefer 真正需要的僅僅只是函數的入口地址和參數，以及它的調用方 deferreturn 的 SP：
// src/runtime/asm_amd64.s// func jmpdefer(fv *funcval, argp uintptr) TEXT runtime·jmpdefer(SB), NOSPLIT, $0-16MOVQ fv+0(FP), DX // DX = fnMOVQ argp+8(FP), BX // 調用方 SPLEAQ -8(BX), SP // CALL 后的調用方 SPMOVQ -8(SP), BP // 恢復 BP，好像 deferreturn 返回SUBQ $5, (SP) // 再次返回到 CALLMOVQ 0(DX), BX // BX = DXJMP BX // 最后才運行被 defer 的函數這個 jmpdefer 巧妙的地方在于，它通過調用方 SP 來推算了 deferreturn 的入口地址，從而在完成某個 defer 調用后，由于被 defer 的函數返回時會出棧，會再次回到 deferreturn 的初始位置，進而繼續反復調用，從而模擬 deferreturn 不斷地對自己進行尾遞歸的假象。
釋放操作非常普通，只是簡單地將其歸還到 P 的 deferpool 中， 并在本地池已滿時將其歸還到全局資源池:
// src/runtime/panic.go//go:nosplit func freedefer(d *_defer) {...sc := deferclass(uintptr(d.siz))if sc >= uintptr(len(p{}.deferpool)) {return}pp := getg().m.p.ptr()// 如果 P 本地池已滿，則將一半資源放入全局池，同樣也是出于性能考慮// 操作會切換到系統棧上執行。if len(pp.deferpool[sc]) == cap(pp.deferpool[sc]) {systemstack(func() {var first, last *_deferfor len(pp.deferpool[sc]) > cap(pp.deferpool[sc])/2 {n := len(pp.deferpool[sc])d := pp.deferpool[sc][n-1]pp.deferpool[sc][n-1] = nilpp.deferpool[sc] = pp.deferpool[sc][:n-1]if first == nil {first = d} else {last.link = d}last = d}lock(&sched.deferlock)last.link = sched.deferpool[sc]sched.deferpool[sc] = firstunlock(&sched.deferlock)})}// 恢復 _defer 的零值，即 *d = _defer{}d.siz = 0...d.sp = 0d.pc = 0d.framepc = 0...d.link = nil// 放入 P 本地資源池pp.deferpool[sc] = append(pp.deferpool[sc], d) }在棧上創建 defer
defer 還可以直接在棧上進行分配，也就是第二種記錄 defer 的形式 deferprocStack。在棧上分配 defer 的好處在于函數返回后 _defer 便已得到釋放，不再需要考慮內存分配時產生的性能開銷，只需要適當地維護 _defer 的鏈表即可。
在 SSA 階段與在堆上分配的區別在于，在棧上創建 defer， 需要直接在函數調用幀上使用編譯器來初始化 _defer 記錄，并作為參數傳遞給 deferprocStack：
// src/cmd/compile/internal/gc/ssa.go func (s *state) call(n *Node, k callKind) *ssa.Value {...var call *ssa.Valueif k == callDeferStack {// 直接在棧上創建 defer 記錄t := deferstruct(stksize) // 從編譯器角度構造 _defer 結構d := tempAt(n.Pos, s.curfn, t)s.vars[&memVar] = s.newValue1A(ssa.OpVarDef, types.TypeMem, d, s.mem())addr := s.addr(d, false)// 在棧上預留記錄 _defer 的各個字段的空間s.store(types.Types[TUINT32],s.newValue1I(ssa.OpOffPtr, types.Types[TUINT32].PtrTo(), t.FieldOff(0), addr),s.constInt32(types.Types[TUINT32], int32(stksize)))s.store(closure.Type,s.newValue1I(ssa.OpOffPtr, closure.Type.PtrTo(), t.FieldOff(6), addr),closure)// 記錄參與 defer 調用的函數參數ft := fn.Typeoff := t.FieldOff(12)args := n.Rlist.Slice()// 調用 deferprocStack，以 _defer 記錄的指針作為參數傳遞arg0 := s.constOffPtrSP(types.Types[TUINTPTR], Ctxt.FixedFrameSize())s.store(types.Types[TUINTPTR], arg0, addr)call = s.newValue1A(ssa.OpStaticCall, types.TypeMem, deferprocStack, s.mem())...} else { ... }// 函數尾聲與堆上分配的棧一樣，調用 deferreturnif k == callDefer || k == callDeferStack {...s.exit()}... }可見，在編譯階段，一個 _defer 記錄的空間已經在棧上得到保留，deferprocStack 的作用就僅僅承擔了運行時對該記錄的初始化這一功能：
// src/runtime/panic.go//go:nosplit func deferprocStack(d *_defer) {gp := getg()// 注意，siz 和 fn 已經在編譯階段完成設置，這里只初始化了其他字段d.started = falsed.heap = false // 可見此時 defer 被標記為不在堆上分配d.openDefer = falsed.sp = getcallersp()d.pc = getcallerpc()...// 盡管在棧上進行分配，仍然需要將多個 _defer 記錄通過鏈表進行串聯，// 以便在 deferreturn 中找到被延遲的函數的入口地址：// d.link = gp._defer// gp._defer = d*(*uintptr)(unsafe.Pointer(&d.link)) = uintptr(unsafe.Pointer(gp._defer))*(*uintptr)(unsafe.Pointer(&gp._defer)) = uintptr(unsafe.Pointer(d))return0() }至于函數尾聲的行為，與在堆上進行分配的操作同樣是調用 deferreturn，我們就不再重復說明了。當然，里面涉及的 freedefer 調用由于不需要釋放任何內存，也就早早返回了：
// src/runtime/panic.go func freedefer(d *_defer) {if !d.heap { return }... }開放編碼式 defer
正如本文最初所描述的那樣，defer 給我們的第一感覺其實是一個編譯期特性。前面我們討論了為什么 defer 會需要運行時的支持，以及需要運行時的 defer 是如何工作的。現在我們來探究一下什么情況下能夠讓 defer 進化為一個僅編譯期特性，即在函數末尾直接對延遲函數進行調用，做到幾乎不需要額外的開銷。這類幾乎不需要額外運行時性能開銷的 defer，正是開放編碼式 defer。這類 defer 與直接調用產生的性能差異有多大呢？我們不妨編寫兩個性能測試：
func call() { func() {}() } func callDefer() { defer func() {}() } func BenchmarkDefer(b *testing.B) {for i := 0; i < b.N; i++ {call() // 第二次運行時替換為 callDefer} }在 Go 1.14 版本下，讀者可以獲得類似下方的性能估計，其中使用 callDefer 后，性能損耗大約為 1 ns。這種納秒級的性能損耗不到一個 CPU 時鐘周期，我們已經可以認為開放編碼式 defer 幾乎沒有了性能開銷：
name old time/op new time/op delta Defer-12 1.24ns ± 1% 2.23ns ± 1% +80.06% (p=0.000 n=10+9)我們再來觀察一下開放編碼式 defer 最終被編譯的形式：
$ go build -gcflags "-l" -ldflags=-compressdwarf=false -o main.out main.go $ go tool objdump -S main.out > main.s對于如下形式的函數調用：
var mu sync.Mutex func callDefer() {mu.Lock()defer mu.Unlock() }整個調用最終編譯結果既沒有 deferproc 或者 deferprocStack，也沒有了 deferreturn。延遲語句被直接插入到了函數的末尾：
TEXT main.callDefer(SB) /Users/changkun/Desktop/defer/main.go func callDefer() {...mu.Lock()0x105794a 488d05071f0a00 LEAQ main.mu(SB), AX 0x1057951 48890424 MOVQ AX, 0(SP) 0x1057955 e8f6f8ffff CALL sync.(*Mutex).Lock(SB) defer mu.Unlock()0x105795a 488d057f110200 LEAQ go.func.*+1064(SB), AX 0x1057961 4889442418 MOVQ AX, 0x18(SP) 0x1057966 488d05eb1e0a00 LEAQ main.mu(SB), AX 0x105796d 4889442410 MOVQ AX, 0x10(SP) }0x1057972 c644240f00 MOVB $0x0, 0xf(SP) 0x1057977 488b442410 MOVQ 0x10(SP), AX 0x105797c 48890424 MOVQ AX, 0(SP) 0x1057980 e8ebfbffff CALL sync.(*Mutex).Unlock(SB) 0x1057985 488b6c2420 MOVQ 0x20(SP), BP 0x105798a 4883c428 ADDQ $0x28, SP 0x105798e c3 RET ...那么開放編碼式 defer 是怎么實現的？所有的 defer 都是開放編碼式的嗎？什么情況下，開放編碼式 defer 會退化為一個依賴運行時的特性？
產生條件
我們先來看開放編碼式 defer 的產生條件。在 SSA 的構建階段 buildssa，我們有：
// src/cmd/compile/internal/gc/ssa.go const maxOpenDefers = 8 func walkstmt(n *Node) *Node {...switch n.Op {case ODEFER:Curfn.Func.SetHasDefer(true)Curfn.Func.numDefers++// 超過 8 個 defer 時，禁用對 defer 進行開放編碼if Curfn.Func.numDefers > maxOpenDefers {Curfn.Func.SetOpenCodedDeferDisallowed(true)}// 存在循環語句中的 defer，禁用對 defer 進行開放編碼。// 是否有 defer 發生在循環語句內，會在 SSA 之前的逃逸分析中進行判斷，// 逃逸分析會檢查是否存在循環（loopDepth）：// if where.Op == ODEFER && e.loopDepth == 1 {// where.Esc = EscNever// ...// }if n.Esc != EscNever {Curfn.Func.SetOpenCodedDeferDisallowed(true)}case ...}... }func buildssa(fn *Node, worker int) *ssa.Func {...var s state...s.hasdefer = fn.Func.HasDefer()...// 可以對 defer 進行開放編碼的條件s.hasOpenDefers = Debug['N'] == 0 && s.hasdefer && !s.curfn.Func.OpenCodedDeferDisallowed()if s.hasOpenDefers &&s.curfn.Func.numReturns*s.curfn.Func.numDefers > 15 {s.hasOpenDefers = false}... }這樣，我們得到了允許進行 defer 的開放編碼的主要條件（此處略去了一些常見生產環境無關的條件，例如啟用競爭檢查時也不能對 defer 進行開放編碼）：
沒有禁用編譯器優化，即沒有設置 -gcflags "-N"
存在 defer 調用
函數內 defer 的數量不超過 8 個、且返回語句與延遲語句個數的乘積不超過 15
沒有 defer 發生在循環語句中
延遲比特
當然，正常編寫的 defer 可以直接被編譯器分析得出，但是如本文開頭提到的，如果一個 defer 發生在一個條件語句中，而這個條件必須等到運行時才能確定：
if rand.Intn(100) < 42 {defer fmt.Println("meaning-of-life") }那么如何才能使用最小的成本，讓插入到函數末尾的延遲語句，在條件成立時候被正確執行呢？這便需要一種機制，能夠記錄存在延遲語句的條件分支是否被執行，這種機制在 Go 中利用了延遲比特（defer bit）。這種做法非常巧妙，但原理卻非常簡單。
對于下面的代碼而言：
defer f1(a1) if cond {defer f2(a2) } ...使用延遲比特的核心思想可以用下面的偽代碼來概括。在創建延遲調用的階段，首先通過延遲比特的特定位置記錄哪些帶條件的 defer 被觸發。這個延遲比特是一個長度為 8 位的二進制碼（也是硬件架構里最小、最通用的情況），以每一位是否被設置為 1，來判斷延遲語句是否在運行時被設置，如果設置，則發生調用。否則則不調用：
deferBits = 0 // 初始值 00000000 deferBits |= 1 << 0 // 遇到第一個 defer，設置為 00000001 _f1 = f1 _a1 = a1 if cond {// 如果第二個 defer 被設置，則設置為 00000011，否則依然為 00000001deferBits |= 1 << 1_f2 = f2_a2 = a2 }在退出位置，再重新根據被標記的延遲比特，反向推導哪些位置的 defer 需要被觸發，從而執行延遲調用：
exit: // 按順序倒序檢查延遲比特。如果第二個 defer 被設置，則 // 00000011 & 00000010 == 00000010，即延遲比特不為零，應該調用 f2。 // 如果第二個 defer 沒有被設置，則 // 00000001 & 00000010 == 00000000，即延遲比特為零，不應該調用 f2。 if deferBits & 1 << 1 != 0 { // 00000011 & 00000010 != 0deferBits &^= 1<<1 // 00000001_f2(_a2) } // 同理，由于 00000001 & 00000001 == 00000001，因此延遲比特不為零，應該調用 f1 if deferBits && 1 << 0 != 0 {deferBits &^= 1<<0_f1(_a1) }在實際的實現中，可以看到，當可以設置開放編碼式 defer 時，buildssa 會首先創建一個長度位 8 位的臨時變量：
// src/cmd/compile/internal/gc/ssa.go func buildssa(fn *Node, worker int) *ssa.Func {...if s.hasOpenDefers {// 創建 deferBits 臨時變量deferBitsTemp := tempAt(src.NoXPos, s.curfn, types.Types[TUINT8])s.deferBitsTemp = deferBitsTemp// deferBits 被設計為 8 位二進制，因此可以被開放編碼的 defer 數量不能超過 8 個// 此處還將起始 deferBits 設置為零startDeferBits := s.entryNewValue0(ssa.OpConst8, types.Types[TUINT8])s.vars[&deferBitsVar] = startDeferBitss.deferBitsAddr = s.addr(deferBitsTemp, false)s.store(types.Types[TUINT8], s.deferBitsAddr, startDeferBits)...}...s.stmtList(fn.Nbody) // 調用 s.stmt... }隨后針對出現 defer 的語句，進行編碼：
// src/cmd/compile/internal/gc/ssa.go func (s *state) stmt(n *Node) {...switch n.Op {case ODEFER:// 開放編碼式 deferif s.hasOpenDefers {s.openDeferRecord(n.Left)} else { ... }case ...}... }// 存儲一個 defer 調用的相關信息，例如所在的語法樹結點、被延遲的調用、參數等等 type openDeferInfo struct {n *Nodeclosure *ssa.ValueclosureNode *Node...argVals []*ssa.ValueargNodes []*Node } func (s *state) openDeferRecord(n *Node) {...var args []*ssa.Valuevar argNodes []*Node// 記錄與 defer 相關的入口地址與參數信息opendefer := &openDeferInfo{n: n}fn := n.Left// 記錄函數入口地址if n.Op == OCALLFUNC {closureVal := s.expr(fn)closure := s.openDeferSave(nil, fn.Type, closureVal)opendefer.closureNode = closure.Aux.(*Node)if !(fn.Op == ONAME && fn.Class() == PFUNC) {opendefer.closure = closure}} else {...}// 記錄需要立即求值的的參數for _, argn := range n.Rlist.Slice() {var v *ssa.Valueif canSSAType(argn.Type) {v = s.openDeferSave(nil, argn.Type, s.expr(argn))} else {v = s.openDeferSave(argn, argn.Type, nil)}args = append(args, v)argNodes = append(argNodes, v.Aux.(*Node))}opendefer.argVals = argsopendefer.argNodes = argNodes// 每多出現一個 defer，len(defers) 會增加，進而 // 延遲比特 deferBits |= 1<<len(defers) 被設置在不同的位上index := len(s.openDefers)s.openDefers = append(s.openDefers, opendefer)bitvalue := s.constInt8(types.Types[TUINT8], 1<<uint(index))newDeferBits := s.newValue2(ssa.OpOr8, types.Types[TUINT8], s.variable(&deferBitsVar, types.Types[TUINT8]), bitvalue)s.vars[&deferBitsVar] = newDeferBitss.store(types.Types[TUINT8], s.deferBitsAddr, newDeferBits) }在函數返回退出前，state 的 exit 函數會依次倒序創建對延遲比特的檢查代碼，從而順序調用被延遲的函數調用：
// src/cmd/compile/internal/gc/ssa.go func (s *state) exit() *ssa.Block {if s.hasdefer {if s.hasOpenDefers {...s.openDeferExit()} else {...}}... }func (s *state) openDeferExit() {deferExit := s.f.NewBlock(ssa.BlockPlain)s.endBlock().AddEdgeTo(deferExit)s.startBlock(deferExit)s.lastDeferExit = deferExits.lastDeferCount = len(s.openDefers)zeroval := s.constInt8(types.Types[TUINT8], 0)// 倒序檢查 deferfor i := len(s.openDefers) - 1; i >= 0; i-- {r := s.openDefers[i]bCond := s.f.NewBlock(ssa.BlockPlain)bEnd := s.f.NewBlock(ssa.BlockPlain)// 檢查 deferBitsdeferBits := s.variable(&deferBitsVar, types.Types[TUINT8])// 創建 if deferBits & 1 << len(defer) != 0 { ... }bitval := s.constInt8(types.Types[TUINT8], 1<<uint(i))andval := s.newValue2(ssa.OpAnd8, types.Types[TUINT8], deferBits, bitval)eqVal := s.newValue2(ssa.OpEq8, types.Types[TBOOL], andval, zeroval)b := s.endBlock()b.Kind = ssa.BlockIfb.SetControl(eqVal)b.AddEdgeTo(bEnd)b.AddEdgeTo(bCond)bCond.AddEdgeTo(bEnd)s.startBlock(bCond)// 如果創建的條件分支被觸發，則清空當前的延遲比特: deferBits &^= 1 << len(defers)nbitval := s.newValue1(ssa.OpCom8, types.Types[TUINT8], bitval)maskedval := s.newValue2(ssa.OpAnd8, types.Types[TUINT8], deferBits, nbitval)s.store(types.Types[TUINT8], s.deferBitsAddr, maskedval)s.vars[&deferBitsVar] = maskedval// 處理被延遲的函數調用，取出保存的入口地址、參數信息argStart := Ctxt.FixedFrameSize()fn := r.n.Leftstksize := fn.Type.ArgWidth()...for j, argAddrVal := range r.argVals {f := getParam(r.n, j)pt := types.NewPtr(f.Type)addr := s.constOffPtrSP(pt, argStart+f.Offset)if !canSSAType(f.Type) {s.move(f.Type, addr, argAddrVal)} else {argVal := s.load(f.Type, argAddrVal)s.storeType(f.Type, addr, argVal, 0, false)}}// 調用var call *ssa.Value...call = s.newValue1A(ssa.OpStaticCall, types.TypeMem, fn.Sym.Linksym(), s.mem())call.AuxInt = stksizes.vars[&memVar] = call...s.endBlock()s.startBlock(bEnd)} }從整個過程中我們可以看到，開放編碼式 defer 并不是絕對的零成本，盡管編譯器能夠做到將延遲調用直接插入返回語句之前，但出于語義的考慮，需要在棧上對參與延遲調用的參數進行一次求值；同時出于條件語句中可能存在的 defer，還額外需要通過延遲比特來記錄一個延遲語句是否在運行時被設置。因此，開放編碼式 defer 的成本體現在非常少量的指令和位運算來配合在運行時判斷是否存在需要被延遲調用的 defer。
defer 的優化之路
我們最后來回顧一下延遲語句的整個演進過程。
defer 的早期實現其實是非常的粗糙的。每當出現一個 defer 調用，都會在堆上分配 defer 記錄，并對參與調用的參數實施一次拷貝操作，然后將其加入到 defer 鏈表上；當函數返回需要觸發 defer 調用時，依次將 defer 從鏈表中取出，完成調用。當然最初的實現并不需要完美，未來總是可以迭代其性能問題。
在 Go 1.1 的開發階段，defer 獲得了它的第一次優化 [Cox, 2011]。Russ Cox 意識到 defer 性能問題的根源是當產生多個 defer 調用時，造成的過多的內存分配與拷貝操作，進而提出將 defer 的分配和釋放過程在每個 Goroutine 內進行批量處理。當時 Dmitry Vyukov 則提議在棧上分配會更加有效，但 Russ Cox 錯誤的認為在執行棧上分配 defer 記錄與在其他地方進行分配并沒有帶來太多收益，最終實現了 per-G 批量式分配的 defer 機制。
由于后續調度器的改進，工作竊取調度的引入，運行時開始支持 per-P 的局部資源池，defer 作為發生在 Goroutine 內的調用，所需的內存自然也是一類可以被視作局部持有的資源。因此分配和釋放 defer 的資源在 Go 1.3 時得到優化 [Vyukov, 2014]，Dmitry Vyukov 將 per-G 分配的 defer 改為了從 per-P 資源池分配的機制。
由于分配延遲記錄 _defer 的調用 newdefer 可能存在本地資源池、全局資源池均不存在可復用的內存，進而導致棧分裂，更糟糕的情況下甚至可能發生搶占，導致 M/P 解綁與綁定等額外的調度開銷。因此，Austin Clements 對 defer 做的一個優化 [Clements, 2016] 是在每個 deferproc 和 deferreturn 中都切換至系統棧，從而阻止了搶占和棧增長的發生，也就優化消除了搶占帶來的 M/P 綁定所帶來的開銷。除此之外，對于每次產生記錄時，無論參數大小如何都涉及 memmove 系統調用，從而產生一次 memmove 的調用成本，Austin 的優化中還特地針對沒有參數和指針大小參數的這兩種情況進行了判斷，從而跳過了這些特殊情況下情況下 memmove 帶來的開銷。
后來，Keith Randall 終于實現了 [Randall, 2013] 很早之前 Dmitry Vyukov 就已經提出的在棧上分配 defer 的優化 [Cox, 2011]，簡單情況下不再需要使用運行時對延遲記錄的內存管理。為 Go 1.13 進一步提升了 defer 的性能。
在 Go 1.14 中，Dan Scales 作為 Go 團隊的新成員，defer 的優化成為了他的第一個項目。他提出開放式編碼 defer [Scales, 2019]，通過編譯器輔助信息和延遲比特在函數末尾處直接獲取調用函數及參數，完成了近乎零成本的 defer 調用，成為了 Go 1.14 中幾個出色的運行時性能優化之一。
至此，defer 的優化之路正式告一段落。
| 1.0 及之前 | 制定 defer 的語言規范，首次實現，在堆上分配 | Robert Griesemer, Ken Thompson |
| 1.1 | 將 defer 的分配與釋放方式改為 per-G 批量處理 | Russ Cox |
| 1.3 | 將 defer 的分配與釋放方式改為 per-P 池化處理 | Dmitry Vyukov |
| 1.8 | 將 defer 的執行過程切換到系統棧中，阻止搶占和棧增長帶來的成本 | Austin Clements |
| 1.13 | 實現在執行棧上分配 defer，消除了常見的簡單情況下堆上分配帶來的開銷 | Keith Randall |
| 1.14 | 實現開放式編碼 defer，支持在函數末尾處直接插入 defer 調用，引入幾乎零成本 defer | Dan Scales |
小結
我們最后來總結一下 defer 的基本工作原理以及三種 defer 的性能取舍，如下圖：
不同類型 defer 的編譯與運行時成本之間的取舍對于開放編碼式 defer 而言：
編譯器會直接將所需的參數進行存儲，并在返回語句的末尾插入被延遲的調用；
當整個調用中邏輯上會執行的 defer 不超過 15 個（例如 7 個 defer 作用在 2 個返回語句）、總 defer 數量不超過 8 個、且沒有出現在循環語句中時，會激活使用此類 defer；
此類 defer 的唯一的運行時成本就是存儲參與延遲調用的相關信息，運行時性能最好。
對于棧上分配的 defer 而言：
編譯器會直接在棧上記錄一個 _defer 記錄，該記錄不涉及內存分配，并將其作為參數，傳入被翻譯為 deferprocStack 的延遲語句，在延遲調用的位置將 _defer 壓入 Goroutine 對應的延遲調用鏈表中；
在函數末尾處，通過編譯器的配合，在調用被 defer 的函數前，調用 deferreturn，將被延遲的調用出棧并執行；
此類 defer 的唯一運行時成本是從 _defer 記錄中將參數復制出，以及從延遲調用記錄鏈表出棧的成本，運行時性能其次。
對于堆上分配的 defer 而言：
編譯器首先會將延遲語句翻譯為一個 deferproc 調用，進而從運行時分配一個用于記錄被延遲調用的 _defer 記錄，并將被延遲的調用的入口地址及其參數復制保存，入棧到 Goroutine 對應的延遲調用鏈表中；
在函數末尾處，通過編譯器的配合，在調用被 defer 的函數前，調用 deferreturn，從而將 _defer 實例歸還到資源池，而后通過模擬尾遞歸的方式來對需要 defer 的函數進行調用。
此類 defer 的主要性能問題存在于每個 defer 語句產生記錄時的內存分配，記錄參數和完成調用時的參數移動時的系統調用，運行時性能最差。
進一步閱讀的參考文獻
[Griesemer, 2009] Robert Griesemer. defer statement. Jan 27, 2009. https://github.com/golang/go/commit/4a903e0b32be5a590880ceb7379e68790602c29d
[Thompson, 2009] Ken Thompson. defer. Jan 27, 2009. https://github.com/golang/go/commit/1e1cc4eb570aa6fec645ff4faf13431847b99db8
[Cox, 2011] Russ Cox. runtime: aggregate defer. Oct, 2011. https://github.com/golang/go/issues/2364
[Clements, 2016] Austin Clements. runtime: optimize defer code. Sep, 2016. https://github.com/golang/go/commit/4c308188cc05d6c26f2a2eb30631f9a368aaa737
[Ma, 2016] Minux Ma. runtime: defer is slow. Mar, 2016. https://github.com/golang/go/issues/14939
[Randall, 2013] Keith Randall. cmd/compile: allocate some defers in stack frames. Dec, 2013. https://github.com/golang/go/issues/6980
[Vyukov, 2014] Dmitry Vyukov. runtime: per-P defer pool. Jan, 2014. https://github.com/golang/go/commit/1ba04c171a3c3a1ea0e5157e8340b606ec9d8949
[Scales, 2019] Dan Scales, Keith Randall, and Austin Clements. Proposal: Low-cost defers through inline code, and extra funcdata to manage the panic case. Sep, 2019. https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers.md
總結
以上是生活随笔為你收集整理的defer 的前世今生的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Go GC 20 问
- 下一篇： 聊聊 g0