[TOC]
# 3.4 延遲語句
延遲語句`defer`在最早期的 Go 語言設計中并不存在，后來才單獨增加了這一特性， 由 Robert Griesemer 完成語言規范的編寫 \[Griesemer, 2009\]， 并由 Ken Thompson 完成最早期的實現 \[Thompson, 2009\]，兩人合作完成這一語言特性。
defer 的語義表明，它會在函數返回、產生恐慌或者`runtime.Goexit`時被調用。直覺上看， defer 應該由編譯器直接將需要的函數調用插入到該調用的地方，似乎是一個編譯期特性， 不應該存在運行時性能問題，非常類似于 C++ 的 RAII 范式（當離開資源的作用域時， 自動執行析構函數）。 但實際情況是，由于 defer 并沒有與其依賴資源掛鉤，也允許在條件、循環語句中出現， 從而不再是一個作用域相關的概念，這就是使得 defer 的語義變得相對復雜。 在一些復雜情況下，無法在編譯期決定存在多少個 defer 調用。
例如，在一個執行次數不確定的 for 循環中，defer 的執行次數是隨機的：
1
2
3
4
5
6
7
8
func randomDefers() {
rand.Seed(time.Now().UnixNano())
for rand.Intn(100) > 42 {
defer func() {
println("golang-design/under-the-hood")
}()
}
}
因而 defer 并不是免費的午餐，在一個復雜的調用中，當無法直接確定需要的產生的延遲調用的數量時， 延遲語句將導致運行性能的下降。本節我們來討論 defer 的實現本質及其對癥下藥的相關性能優化手段。
## 3.4.1 defer 的類型
延遲語句的文法產生式`DeferStmt -> "defer" Expression`的描述非常的簡單，因而也 很容易將其處理為語法樹的形式，但我們這里更關心的其實是它語義背后的中間和目標代碼的形式。
在[5.2 Go 程序編譯流程](https://golang.design/under-the-hood/zh-cn/part1basic/ch05life/compile)一節中我們提到過， 在進行中間代碼生成階段時，會通過`compileSSA`先調用`buildssa`為函數體生成 SSA 形式的函數， 并而后調用`genssa`將函數的 SSA 中間表示轉換為具體的指令。
Go 語言的語句在執行`buildssa`階段中，會由`state.stmt`完成函數中各個語句 SSA 處理。
1
2
3
4
5
6
7
8
9
10
// 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)**的延遲語句。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// src/cmd/compile/internal/gc/ssa.go
func (s *state) stmt(n *Node) {
...
switch n.Op {
case ODEFER:
// 開放編碼式 defer
if s.hasOpenDefers {
s.openDeferRecord(n.Left)
} else {
// 堆上分配的 defer
d := callDefer
if n.Esc == EscNever {
// 棧上分配的 defer
d = callDeferStack
}
s.call(n.Left, d)
}
case ...
}
...
}
## 3.4.2 在堆上分配的 defer
我們先來討論最簡單的在堆上分配的 defer 這種形式。在堆上分配的原因是 defer 語句出現 在了循環語句里，或者無法執行更高階的編譯器優化導致的。如果一個與 defer 出現在循環語句中， 則可執行的次數可能無法在編譯期決定；如果一個調用中 defer 由于數量過多等原因， 不能被編譯器進行開放編碼，則也會在堆上分配 defer。
總之，由于這種不確定性的存在，在堆上分配的 defer 需要最多的運行時支持， 因而產生的運行時開銷也最大。
### 編譯階段
為了使延遲語句的功能滿足語言規范，該語句在編譯的 SSA 階段會被翻譯為兩個主體， 其中第一個主體是被延遲的函數本身，另一個主體則是函數結束時需要執行所記錄 defer 的代碼塊。
`state.call`調用會生成用于記錄延遲調用參數的指令，并創建一個`deferproc`的調用指令； 而后在`state.exit`調用在函數返回前插入`deferreturn`調用的指令。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// src/cmd/compile/internal/gc/ssa.go
func (s *state) call(n *Node, k callKind) *ssa.Value {
...
var call *ssa.Value
if k == callDeferStack {
...
} else {
// 在堆上創建 defer
argStart := 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) // 保存參數大小 siz
addr = s.constOffPtrSP(s.f.Config.Types.UintptrPtr, argStart+int64(Widthptr))
s.store(types.Types[TUINTPTR], addr, closure) // 保存函數地址 fn
stksize += 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 {
// 調用 deferreturn
s.rtcall(Deferreturn, true, nil)
}
}
...
}
例如，對于一個純粹的`defer`調用而言：
~~~
package main
func foo() {
return
}
func main() {
defer foo()
return
}
~~~
如果我們將其強制編譯為在堆上分配的形式，可以觀察到如下的匯編代碼。其中`defer foo()`被轉化為了`deferproc`調用，并在函數返回前，調用了`deferreturn`：
~~~
TEXT main.foo(SB) /Users/changkun/Desktop/defer/ssa/main.go
return
0x104ea20 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，如圖 3.4.1 所示。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// src/runtime/panic.go
type _defer struct {
siz int32
heap bool
sp uintptr
pc uintptr
fn *funcval
link *_defer
...
}
// src/runtime/runtime2.go
type g struct {
...
_defer *_defer
...
}
**圖 3.4.1：附著在 Goroutine 上的`_defer`記錄的鏈表**
現在我們知道，一個在堆上分配的延遲語句被編譯為了`deferproc`，用于記錄被延遲的函數調用； 在函數的尾聲，會插入`deferreturn`調用，用于執行被延遲的調用。
下面我們就來詳細看看這兩個調用具體發生了什么事情。
我們先看創建 defer 的第一種形式`deferproc`。 這個調用很簡單，僅僅只是將需要被 defer 調用的函數做了一次記錄：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
//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 = fn
d.pc = callerpc
d.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 個字節分一個等級。此做法的動機與運行時內存分配器針對不同大小對象的分配思路雷同， 這里不再做深入討論。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/runtime/runtime2.go
type p struct {
...
// 不同大小的本地 defer 池
deferpool [5][]*_defer
deferpoolbuf [5][32]*_defer
...
}
type schedt struct {
...
// 不同大小的全局 defer 池
deferlock mutex
deferpool [5]*_defer
...
}
對于新建的`_defer`實例而言，會將其加入到 Goroutine 所保留的 defer 鏈表上， 通過`link`字段串聯。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// src/runtime/panic.go
//go:nosplit
func newdefer(siz int32) *_defer {
var d *_defer
sc := 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.link
d.link = nil
pp.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] = nil
pp.deferpool[sc] = pp.deferpool[sc][:n-1]
}
}
// 沒有可用的緩存，直接從堆上分配新的 defer 和 args
if d == nil {
systemstack(func() {
total := roundupsize(totaldefersize(uintptr(siz)))
d = (*_defer)(mallocgc(total, deferType, true))
})
}
// 將 _defer 實例添加到 Goroutine 的 _defer 鏈表上。
d.siz = siz
d.heap = true
d.link = gp._defer
gp._defer = d
return d
}
`deferreturn`被編譯器插入到函數末尾，當跳轉到它時，會將需要被 defer 的入口地址取出， 然后跳轉并執行：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// src/runtime/panic.go
//go:nosplit
func deferreturn(arg0 uintptr) {
gp := getg()
d := gp._defer
if 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.fn
d.fn = nil
gp._defer = d.link
freedefer(d)
// 調用，并跳轉到下一個 defer
jmpdefer(fn, uintptr(unsafe.Pointer(&arg0)))
}
在這個函數中，會在需要時對`defer`的參數再次進行拷貝，多個`defer`函數以`jmpdefer`尾調用形式被實現。 在跳轉到`fn`之前，`_defer`實例被釋放歸還，`jmpdefer`真正需要的僅僅只是函數的入口地址和參數， 以及它的調用方`deferreturn`的 SP：
1
2
3
4
5
6
7
8
9
10
11
// src/runtime/asm_amd64.s
// func jmpdefer(fv *funcval, argp uintptr)
TEXT runtime·jmpdefer(SB), NOSPLIT, $0-16
MOVQ fv+0(FP), DX // DX = fn
MOVQ argp+8(FP), BX // 調用方 SP
LEAQ -8(BX), SP // CALL 后的調用方 SP
MOVQ -8(SP), BP // 恢復 BP，好像 deferreturn 返回
SUBQ $5, (SP) // 再次返回到 CALL
MOVQ 0(DX), BX // BX = DX
JMP BX // 最后才運行被 defer 的函數
這個`jmpdefer`巧妙的地方在于，它通過調用方 SP 來推算了`deferreturn`的入口地址， 從而在完成某個`defer`調用后，由于被 defer 的函數返回時會出棧， 會再次回到`deferreturn`的初始位置，進而繼續反復調用，從而模擬`deferreturn`不斷的對自己進行尾遞歸的假象。
上面的描述可能不太容易理解，我們再舉一個實際的例子：
1
2
3
4
5
6
7
8
9
10
11
12
package main
func foo() {
for i := 1; i <= 42; i++ {
defer func(i int) { println(i) }(i)
}
return
}
func main() {
foo()
}
TODO: 繪圖
釋放操作非常普通，只是簡單的將其歸還到 P 的`deferpool`中， 并在本地池已滿時將其歸還到全局資源池:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
// 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 *_defer
for 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] = nil
pp.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] = first
unlock(&sched.deferlock)
})
}
// 恢復 _defer 的零值，即 *d = _defer{}
d.siz = 0
...
d.sp = 0
d.pc = 0
d.framepc = 0
...
d.link = nil
// 放入 P 本地資源池
pp.deferpool[sc] = append(pp.deferpool[sc], d)
}
## 3.4.3 在棧上創建 defer
defer 還可以直接在棧上進行分配，也就是第二種記錄 defer 的形式`deferprocStack`。 在棧上分配 defer 的好處在于函數返回后`_defer`便已得到釋放， 不再需要考慮內存分配時產生的性能開銷，只需要適當的維護`_defer`的鏈表即可。
在 SSA 階段與在堆上分配的區別在于，在棧上創建 defer， 需要直接在函數調用幀上使用編譯器來初始化`_defer`記錄，并作為參數傳遞給`deferprocStack`：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// src/cmd/compile/internal/gc/ssa.go
func (s *state) call(n *Node, k callKind) *ssa.Value {
...
var call *ssa.Value
if 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.Type
off := 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 { ... }
// 函數尾聲與堆上分配的棧一樣，調用 deferreturn
if k == callDefer || k == callDeferStack {
...
s.exit()
}
...
}
可見，在編譯階段，一個`_defer`記錄的空間已經在棧上得到保留，`deferprocStack`的作用 就僅僅承擔了運行時對該記錄的初始化這一功能：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// src/runtime/panic.go
//go:nosplit
func deferprocStack(d *_defer) {
gp := getg()
// 注意，siz 和 fn 已經在編譯階段完成設置，這里只初始化了其他字段
d.started = false
d.heap = false // 可見此時 defer 被標記為不在堆上分配
d.openDefer = false
d.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`調用由于不需要釋放任何內存，也就早早返回了：
1
2
3
4
5
// src/runtime/panic.go
func freedefer(d *_defer) {
if !d.heap { return }
...
}
## 3.4.3 開放編碼式 defer
正如本節最初所描述的那樣，defer 給我們的第一感覺其實是一個編譯期特性。前面我們討論了 為什么 defer 會需要運行時的支持，以及需要運行時的 defer 是如何工作的。現在我們來 探究一下什么情況下能夠讓 defer 進化為一個僅編譯期特性，即在函數末尾直接對延遲函數進行調用， 做到幾乎不需要額外的開銷。這類幾乎不需要額外運行時性能開銷的 defer，正是開放編碼式 defer。 這類 defer 與直接調用產生的性能差異有多大呢？我們不妨編寫兩個性能測試：
1
2
3
4
5
6
7
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 最終被編譯的形式：
1
2
$ go build -gcflags "-l" -ldflags=-compressdwarf=false -o main.out main.go
$ go tool objdump -S main.out > main.s
對于如下形式的函數調用：
1
2
3
4
5
var mu sync.Mutex
func callDefer() {
mu.Lock()
defer mu.Unlock()
}
整個調用最終編譯結果既沒有`deferproc`或者`deferprocStack`，也沒有了`deferreturn`。 延遲語句被直接插入到了函數的末尾：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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`，我們有：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// 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 進行開放編碼）：
1. 沒有禁用編譯器優化，即沒有設置`-gcflags "-N"`
2. 存在 defer 調用
3. 函數內 defer 的數量不超過 8 個、且返回語句與延遲語句個數的乘積不超過 15
4. 沒有與 defer 發生在循環語句中
### 延遲比特
當然，正常編寫的`defer`可以直接被編譯器分析得出，但是如本節開頭提到的，如果一個 defer 發生在一個條件語句中，而這個條件必須等到運行時才能確定：
1
2
3
if rand.Intn(100) < 42 {
defer fmt.Println("meaning-of-life")
}
那么如何才能使用最小的成本，讓插入到函數末尾的延遲語句，在條件成立時候被正確執行呢？ 這便需要一種機制，能夠記錄存在延遲語句的條件分支是否被執行， 這種機制在 Go 中利用了延遲比特（defer bit）。這種做法非常巧妙，但原理卻非常簡單。
對于下面的代碼而言：
1
2
3
4
5
defer f1(a1)
if cond {
defer f2(a2)
}
...
使用延遲比特的核心思想可以用下面的偽代碼來概括。 在創建延遲調用的階段，首先通過延遲比特的特定位置記錄哪些帶條件的 defer 被觸發。 這個延遲比特是一個長度為 8 位的二進制碼（也是硬件架構里最小、最通用的情況）， 以每一位是否被設置為 1，來判斷延遲語句是否在運行時被設置，如果設置，則發生調用。 否則則不調用：
1
2
3
4
5
6
7
8
9
10
deferBits = 0 // 初始值 00000000
deferBits |= 1 << 0 // 遇到第一個 defer，設置為 00000001
_f1 = f1
_a1 = a1
if cond {
// 如果第二個 defer 被設置，則設置為 00000011，否則依然為 00000001
deferBits |= 1 << 1
_f2 = f2
_a2 = a2
}
在退出位置，再重新根據被標記的延遲比特，反向推導哪些位置的 defer 需要被觸發，從而 執行延遲調用：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
exit:
// 按順序倒序檢查延遲比特。如果第二個 defer 被設置，則
// 00000011 & 00000010 == 00000010，即延遲比特不為零，應該調用 f2。
// 如果第二個 defer 沒有被設置，則
// 00000001 & 00000010 == 00000000，即延遲比特為零，不應該調用 f2。
if deferBits & 1 << 1 != 0 { // 00000011 & 00000010 != 0
deferBits &^= 1<<1 // 00000001
_f2(_a2)
}
// 同理，由于 00000001 & 00000001 == 00000001，因此延遲比特不為零，應該調用 f1
if deferBits && 1 << 0 != 0 {
deferBits &^= 1<<0
_f1(_a1)
}
在實際的實現中，可以看到，當可以設置開放編碼式 defer 時，`buildssa`會首先創建一個 長度位 8 位的臨時變量：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 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] = startDeferBits
s.deferBitsAddr = s.addr(deferBitsTemp, false)
s.store(types.Types[TUINT8], s.deferBitsAddr, startDeferBits)
...
}
...
s.stmtList(fn.Nbody) // 調用 s.stmt
...
}
隨后針對出現 defer 的語句，進行編碼：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// src/cmd/compile/internal/gc/ssa.go
func (s *state) stmt(n *Node) {
...
switch n.Op {
case ODEFER:
// 開放編碼式 defer
if s.hasOpenDefers {
s.openDeferRecord(n.Left)
} else { ... }
case ...
}
...
}
// 存儲一個 defer 調用的相關信息，例如所在的語法樹結點、被延遲的調用、參數等等
type openDeferInfo struct {
n *Node
closure *ssa.Value
closureNode *Node
...
argVals []*ssa.Value
argNodes []*Node
}
func (s *state) openDeferRecord(n *Node) {
...
var args []*ssa.Value
var 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.Value
if 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 = args
opendefer.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] = newDeferBits
s.store(types.Types[TUINT8], s.deferBitsAddr, newDeferBits)
}
在函數返回退出前，`state`的`exit`函數會依次倒序創建對延遲比特的檢查代碼， 從而順序調用被延遲的函數調用：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// 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 = deferExit
s.lastDeferCount = len(s.openDefers)
zeroval := s.constInt8(types.Types[TUINT8], 0)
// 倒序檢查 defer
for i := len(s.openDefers) - 1; i >= 0; i-- {
r := s.openDefers[i]
bCond := s.f.NewBlock(ssa.BlockPlain)
bEnd := s.f.NewBlock(ssa.BlockPlain)
// 檢查 deferBits
deferBits := 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.BlockIf
b.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.Left
stksize := 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 = stksize
s.vars[&memVar] = call
...
s.endBlock()
s.startBlock(bEnd)
}
}
從整個過程中我們可以看到，開放編碼式 defer 并不是絕對的零成本，盡管編譯器能夠做到將 延遲調用直接插入返回語句之前，但出于語義的考慮，需要在棧上對參與延遲調用的參數進行一次求值； 同時出于條件語句中可能存在的 defer，還額外需要通過延遲比特來記錄一個延遲語句是否在運行時 被設置。 因此，開放編碼式 defer 的成本體現在非常少量的指令和位運算來配合在運行時判斷 是否存在需要被延遲調用的 defer。
## 3.4.4`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 |
## 3.4.5 小結
**圖 3.4.2：不同類型 defer 的編譯與運行時成本之間的取舍**
我們最后來總結一下 defer 的基本工作原理以及三種 defer 的性能取舍，見圖 3.4.2。
1. 對于開放編碼式 defer 而言：
* 編譯器會直接將所需的參數進行存儲，并在返回語句的末尾插入被延遲的調用；
* 當整個調用中邏輯上會執行的 defer 不超過 15 個（例如七個 defer 作用在兩個返回語句）、總 defer 數量不超過 8 個、且沒有出現在循環語句中時，會激活使用此類 defer；
* 此類 defer 的唯一的運行時成本就是存儲參與延遲調用的相關信息，運行時性能最好。
2. 對于棧上分配的 defer 而言：
* 編譯器會直接在棧上記錄一個`_defer`記錄，該記錄不涉及內存分配，并將其作為參數，傳入被翻譯為`deferprocStack`的延遲語句，在延遲調用的位置將`_defer`壓入 Goroutine 對應的延遲調用鏈表中；
* 在函數末尾處，通過編譯器的配合，在調用被 defer 的函數前，調用`deferreturn`，將被延遲的調用出棧并執行；
* 此類 defer 的唯一運行時成本是從`_defer`記錄中將參數復制出，以及從延遲調用記錄鏈表出棧的成本，運行時性能其次。
3. 對于堆上分配的 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](https://github.com/golang/go/commit/4a903e0b32be5a590880ceb7379e68790602c29d)
* \[Thompson, 2009\] Ken Thompson. defer. Jan 27, 2009.[https://github.com/golang/go/commit/1e1cc4eb570aa6fec645ff4faf13431847b99db8](https://github.com/golang/go/commit/1e1cc4eb570aa6fec645ff4faf13431847b99db8)
* \[Cox, 2011\] Russ Cox. runtime: aggregate defer. Oct, 2011.[https://github.com/golang/go/issues/2364](https://github.com/golang/go/issues/2364)
* \[Clements, 2016\] Austin Clements. runtime: optimize defer code. Sep, 2016.[https://github.com/golang/go/commit/4c308188cc05d6c26f2a2eb30631f9a368aaa737](https://github.com/golang/go/commit/4c308188cc05d6c26f2a2eb30631f9a368aaa737)
* \[Ma, 2016\] Minux Ma. runtime: defer is slow. Mar, 2016.[https://github.com/golang/go/issues/14939](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](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](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](https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers)# 3.4 延遲語句
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
// src/cmd/compile/internal/gc/ssa.go
func (s *state) call(n *Node, k callKind) *ssa.Value {
...
var call *ssa.Value
if 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.Type
off := 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 { ... }
// 函數尾聲與堆上分配的棧一樣，調用 deferreturn
if k == callDefer || k == callDeferStack {
...
s.exit()
}
...
}
可見，在編譯階段，一個`_defer`記錄的空間已經在棧上得到保留，`deferprocStack`的作用 就僅僅承擔了運行時對該記錄的初始化這一功能：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
// src/runtime/panic.go
//go:nosplit
func deferprocStack(d *_defer) {
gp := getg()
// 注意，siz 和 fn 已經在編譯階段完成設置，這里只初始化了其他字段
d.started = false
d.heap = false // 可見此時 defer 被標記為不在堆上分配
d.openDefer = false
d.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`調用由于不需要釋放任何內存，也就早早返回了：
1
2
3
4
5
// src/runtime/panic.go
func freedefer(d *_defer) {
if !d.heap { return }
...
}
## 3.4.3 開放編碼式 defer
正如本節最初所描述的那樣，defer 給我們的第一感覺其實是一個編譯期特性。前面我們討論了 為什么 defer 會需要運行時的支持，以及需要運行時的 defer 是如何工作的。現在我們來 探究一下什么情況下能夠讓 defer 進化為一個僅編譯期特性，即在函數末尾直接對延遲函數進行調用， 做到幾乎不需要額外的開銷。這類幾乎不需要額外運行時性能開銷的 defer，正是開放編碼式 defer。 這類 defer 與直接調用產生的性能差異有多大呢？我們不妨編寫兩個性能測試：
1
2
3
4
5
6
7
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 最終被編譯的形式：
1
2
$ go build -gcflags "-l" -ldflags=-compressdwarf=false -o main.out main.go
$ go tool objdump -S main.out > main.s
對于如下形式的函數調用：
1
2
3
4
5
var mu sync.Mutex
func callDefer() {
mu.Lock()
defer mu.Unlock()
}
整個調用最終編譯結果既沒有`deferproc`或者`deferprocStack`，也沒有了`deferreturn`。 延遲語句被直接插入到了函數的末尾：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
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`，我們有：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
// 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 進行開放編碼）：
1. 沒有禁用編譯器優化，即沒有設置`-gcflags "-N"`
2. 存在 defer 調用
3. 函數內 defer 的數量不超過 8 個、且返回語句與延遲語句個數的乘積不超過 15
4. 沒有與 defer 發生在循環語句中
### 延遲比特
當然，正常編寫的`defer`可以直接被編譯器分析得出，但是如本節開頭提到的，如果一個 defer 發生在一個條件語句中，而這個條件必須等到運行時才能確定：
1
2
3
if rand.Intn(100) < 42 {
defer fmt.Println("meaning-of-life")
}
那么如何才能使用最小的成本，讓插入到函數末尾的延遲語句，在條件成立時候被正確執行呢？ 這便需要一種機制，能夠記錄存在延遲語句的條件分支是否被執行， 這種機制在 Go 中利用了延遲比特（defer bit）。這種做法非常巧妙，但原理卻非常簡單。
對于下面的代碼而言：
1
2
3
4
5
defer f1(a1)
if cond {
defer f2(a2)
}
...
使用延遲比特的核心思想可以用下面的偽代碼來概括。 在創建延遲調用的階段，首先通過延遲比特的特定位置記錄哪些帶條件的 defer 被觸發。 這個延遲比特是一個長度為 8 位的二進制碼（也是硬件架構里最小、最通用的情況）， 以每一位是否被設置為 1，來判斷延遲語句是否在運行時被設置，如果設置，則發生調用。 否則則不調用：
1
2
3
4
5
6
7
8
9
10
deferBits = 0 // 初始值 00000000
deferBits |= 1 << 0 // 遇到第一個 defer，設置為 00000001
_f1 = f1
_a1 = a1
if cond {
// 如果第二個 defer 被設置，則設置為 00000011，否則依然為 00000001
deferBits |= 1 << 1
_f2 = f2
_a2 = a2
}
在退出位置，再重新根據被標記的延遲比特，反向推導哪些位置的 defer 需要被觸發，從而 執行延遲調用：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
exit:
// 按順序倒序檢查延遲比特。如果第二個 defer 被設置，則
// 00000011 & 00000010 == 00000010，即延遲比特不為零，應該調用 f2。
// 如果第二個 defer 沒有被設置，則
// 00000001 & 00000010 == 00000000，即延遲比特為零，不應該調用 f2。
if deferBits & 1 << 1 != 0 { // 00000011 & 00000010 != 0
deferBits &^= 1<<1 // 00000001
_f2(_a2)
}
// 同理，由于 00000001 & 00000001 == 00000001，因此延遲比特不為零，應該調用 f1
if deferBits && 1 << 0 != 0 {
deferBits &^= 1<<0
_f1(_a1)
}
在實際的實現中，可以看到，當可以設置開放編碼式 defer 時，`buildssa`會首先創建一個 長度位 8 位的臨時變量：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 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] = startDeferBits
s.deferBitsAddr = s.addr(deferBitsTemp, false)
s.store(types.Types[TUINT8], s.deferBitsAddr, startDeferBits)
...
}
...
s.stmtList(fn.Nbody) // 調用 s.stmt
...
}
隨后針對出現 defer 的語句，進行編碼：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
// src/cmd/compile/internal/gc/ssa.go
func (s *state) stmt(n *Node) {
...
switch n.Op {
case ODEFER:
// 開放編碼式 defer
if s.hasOpenDefers {
s.openDeferRecord(n.Left)
} else { ... }
case ...
}
...
}
// 存儲一個 defer 調用的相關信息，例如所在的語法樹結點、被延遲的調用、參數等等
type openDeferInfo struct {
n *Node
closure *ssa.Value
closureNode *Node
...
argVals []*ssa.Value
argNodes []*Node
}
func (s *state) openDeferRecord(n *Node) {
...
var args []*ssa.Value
var 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.Value
if 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 = args
opendefer.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] = newDeferBits
s.store(types.Types[TUINT8], s.deferBitsAddr, newDeferBits)
}
在函數返回退出前，`state`的`exit`函數會依次倒序創建對延遲比特的檢查代碼， 從而順序調用被延遲的函數調用：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
// 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 = deferExit
s.lastDeferCount = len(s.openDefers)
zeroval := s.constInt8(types.Types[TUINT8], 0)
// 倒序檢查 defer
for i := len(s.openDefers) - 1; i >= 0; i-- {
r := s.openDefers[i]
bCond := s.f.NewBlock(ssa.BlockPlain)
bEnd := s.f.NewBlock(ssa.BlockPlain)
// 檢查 deferBits
deferBits := 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.BlockIf
b.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.Left
stksize := 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 = stksize
s.vars[&memVar] = call
...
s.endBlock()
s.startBlock(bEnd)
}
}
從整個過程中我們可以看到，開放編碼式 defer 并不是絕對的零成本，盡管編譯器能夠做到將 延遲調用直接插入返回語句之前，但出于語義的考慮，需要在棧上對參與延遲調用的參數進行一次求值； 同時出于條件語句中可能存在的 defer，還額外需要通過延遲比特來記錄一個延遲語句是否在運行時 被設置。 因此，開放編碼式 defer 的成本體現在非常少量的指令和位運算來配合在運行時判斷 是否存在需要被延遲調用的 defer。
## 3.4.4`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 |
## 3.4.5 小結
**圖 3.4.2：不同類型 defer 的編譯與運行時成本之間的取舍**
我們最后來總結一下 defer 的基本工作原理以及三種 defer 的性能取舍，見圖 3.4.2。
1. 對于開放編碼式 defer 而言：
* 編譯器會直接將所需的參數進行存儲，并在返回語句的末尾插入被延遲的調用；
* 當整個調用中邏輯上會執行的 defer 不超過 15 個（例如七個 defer 作用在兩個返回語句）、總 defer 數量不超過 8 個、且沒有出現在循環語句中時，會激活使用此類 defer；
* 此類 defer 的唯一的運行時成本就是存儲參與延遲調用的相關信息，運行時性能最好。
2. 對于棧上分配的 defer 而言：
* 編譯器會直接在棧上記錄一個`_defer`記錄，該記錄不涉及內存分配，并將其作為參數，傳入被翻譯為`deferprocStack`的延遲語句，在延遲調用的位置將`_defer`壓入 Goroutine 對應的延遲調用鏈表中；
* 在函數末尾處，通過編譯器的配合，在調用被 defer 的函數前，調用`deferreturn`，將被延遲的調用出棧并執行；
* 此類 defer 的唯一運行時成本是從`_defer`記錄中將參數復制出，以及從延遲調用記錄鏈表出棧的成本，運行時性能其次。
3. 對于堆上分配的 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](https://github.com/golang/go/commit/4a903e0b32be5a590880ceb7379e68790602c29d)
* \[Thompson, 2009\] Ken Thompson. defer. Jan 27, 2009.[https://github.com/golang/go/commit/1e1cc4eb570aa6fec645ff4faf13431847b99db8](https://github.com/golang/go/commit/1e1cc4eb570aa6fec645ff4faf13431847b99db8)
* \[Cox, 2011\] Russ Cox. runtime: aggregate defer. Oct, 2011.[https://github.com/golang/go/issues/2364](https://github.com/golang/go/issues/2364)
* \[Clements, 2016\] Austin Clements. runtime: optimize defer code. Sep, 2016.[https://github.com/golang/go/commit/4c308188cc05d6c26f2a2eb30631f9a368aaa737](https://github.com/golang/go/commit/4c308188cc05d6c26f2a2eb30631f9a368aaa737)
* \[Ma, 2016\] Minux Ma. runtime: defer is slow. Mar, 2016.[https://github.com/golang/go/issues/14939](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](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](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](https://go.googlesource.com/proposal/+/refs/heads/master/design/34481-opencoded-defers)# 3.4 延遲語句
延遲語句`defer`在最早期的 Go 語言設計中并不存在，后來才單獨增加了這一特性， 由 Robert Griesemer 完成語言規范的編寫 \[Griesemer, 2009\]， 并由 Ken Thompson 完成最早期的實現 \[Thompson, 2009\]，兩人合作完成這一語言特性。
defer 的語義表明，它會在函數返回、產生恐慌或者`runtime.Goexit`時被調用。直覺上看， defer 應該由編譯器直接將需要的函數調用插入到該調用的地方，似乎是一個編譯期特性， 不應該存在運行時性能問題，非常類似于 C++ 的 RAII 范式（當離開資源的作用域時， 自動執行析構函數）。 但實際情況是，由于 defer 并沒有與其依賴資源掛鉤，也允許在條件、循環語句中出現， 從而不再是一個作用域相關的概念，這就是使得 defer 的語義變得相對復雜。 在一些復雜情況下，無法在編譯期決定存在多少個 defer 調用。
例如，在一個執行次數不確定的 for 循環中，defer 的執行次數是隨機的：
1
2
3
4
5
6
7
8
func randomDefers() {
rand.Seed(time.Now().UnixNano())
for rand.Intn(100) > 42 {
defer func() {
println("golang-design/under-the-hood")
}()
}
}
因而 defer 并不是免費的午餐，在一個復雜的調用中，當無法直接確定需要的產生的延遲調用的數量時， 延遲語句將導致運行性能的下降。本節我們來討論 defer 的實現本質及其對癥下藥的相關性能優化手段。
## 3.4.1 defer 的類型
延遲語句的文法產生式`DeferStmt -> "defer" Expression`的描述非常的簡單，因而也 很容易將其處理為語法樹的形式，但我們這里更關心的其實是它語義背后的中間和目標代碼的形式。
在[5.2 Go 程序編譯流程](https://golang.design/under-the-hood/zh-cn/part1basic/ch05life/compile)一節中我們提到過， 在進行中間代碼生成階段時，會通過`compileSSA`先調用`buildssa`為函數體生成 SSA 形式的函數， 并而后調用`genssa`將函數的 SSA 中間表示轉換為具體的指令。
Go 語言的語句在執行`buildssa`階段中，會由`state.stmt`完成函數中各個語句 SSA 處理。
1
2
3
4
5
6
7
8
9
10
// 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)**的延遲語句。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// src/cmd/compile/internal/gc/ssa.go
func (s *state) stmt(n *Node) {
...
switch n.Op {
case ODEFER:
// 開放編碼式 defer
if s.hasOpenDefers {
s.openDeferRecord(n.Left)
} else {
// 堆上分配的 defer
d := callDefer
if n.Esc == EscNever {
// 棧上分配的 defer
d = callDeferStack
}
s.call(n.Left, d)
}
case ...
}
...
}
## 3.4.2 在堆上分配的 defer
我們先來討論最簡單的在堆上分配的 defer 這種形式。在堆上分配的原因是 defer 語句出現 在了循環語句里，或者無法執行更高階的編譯器優化導致的。如果一個與 defer 出現在循環語句中， 則可執行的次數可能無法在編譯期決定；如果一個調用中 defer 由于數量過多等原因， 不能被編譯器進行開放編碼，則也會在堆上分配 defer。
總之，由于這種不確定性的存在，在堆上分配的 defer 需要最多的運行時支持， 因而產生的運行時開銷也最大。
### 編譯階段
- 第一部分 :基礎篇
- 第1章 Go語言的前世今生
- 1.2 Go語言綜述
- 1.3 順序進程通訊
- 1.4 Plan9匯編語言
- 第2章 程序生命周期
- 2.1 從go命令談起
- 2.2 Go程序編譯流程
- 2.3 Go 程序啟動引導
- 2.4 主Goroutine的生與死
- 第3 章 語言核心
- 3.1 數組.切片與字符串
- 3.2 散列表
- 3.3 函數調用
- 3.4 延遲語句
- 3.5 恐慌與恢復內建函數
- 3.6 通信原語
- 3.7 接口
- 3.8 運行時類型系統
- 3.9 類型別名
- 3.10 進一步閱讀的參考文獻
- 第4章 錯誤
- 4.1 問題的演化
- 4.2 錯誤值檢查
- 4.3 錯誤格式與上下文
- 4.4 錯誤語義
- 4.5 錯誤處理的未來
- 4.6 進一步閱讀的參考文獻
- 第5章 同步模式
- 5.1 共享內存式同步模式
- 5.2 互斥鎖
- 5.3 原子操作
- 5.4 條件變量
- 5.5 同步組
- 5.6 緩存池
- 5.7 并發安全散列表
- 5.8 上下文
- 5.9 內存一致模型
- 5.10 進一步閱讀的文獻參考
- 第二部分 運行時篇
- 第6章 并發調度
- 6.1 隨機調度的基本概念
- 6.2 工作竊取式調度
- 6.3 MPG模型與并發調度單
- 6.4 調度循環
- 6.5 線程管理
- 6.6 信號處理機制
- 6.7 執行棧管理
- 6.8 協作與搶占
- 6.9 系統監控
- 6.10 網絡輪詢器
- 6.11 計時器
- 6.12 非均勻訪存下的調度模型
- 6.13 進一步閱讀的參考文獻
- 第7章 內存分配
- 7.1 設計原則
- 7.2 組件
- 7.3 初始化
- 7.4 大對象分配
- 7.5 小對象分配
- 7.6 微對象分配
- 7.7 頁分配器
- 7.8 內存統計
- 第8章 垃圾回收
- 8.1 垃圾回收的基本想法
- 8.2 寫屏幕技術
- 8.3 調步模型與強弱觸發邊界
- 8.4 掃描標記與標記輔助
- 8.5 免清掃式位圖技術
- 8.6 前進保障與終止檢測
- 8.7 安全點分析
- 8.8 分代假設與代際回收
- 8.9 請求假設與實務制導回收
- 8.10 終結器
- 8.11 過去,現在與未來
- 8.12 垃圾回收統一理論
- 8.13 進一步閱讀的參考文獻
- 第三部分 工具鏈篇
- 第9章 代碼分析
- 9.1 死鎖檢測
- 9.2 競爭檢測
- 9.3 性能追蹤
- 9.4 代碼測試
- 9.5 基準測試
- 9.6 運行時統計量
- 9.7 語言服務協議
- 第10章 依賴管理
- 10.1 依賴管理的難點
- 10.2 語義化版本管理
- 10.3 最小版本選擇算法
- 10.4 Vgo 與dep之爭
- 第12章 泛型
- 12.1 泛型設計的演進
- 12.2 基于合約的泛型
- 12.3 類型檢查技術
- 12.4 泛型的未來
- 12.5 進一步閱讀的的參考文獻
- 第13章 編譯技術
- 13.1 詞法與文法
- 13.2 中間表示
- 13.3 優化器
- 13.4 指針檢查器
- 13.5 逃逸分析
- 13.6 自舉
- 13.7 鏈接器
- 13.8 匯編器
- 13.9 調用規約
- 13.10 cgo與系統調用
- 結束語: Go去向何方?