上篇文章golang中defer的執(zhí)行過程是怎樣的？介紹了一下defer的執(zhí)行過程，本篇是上一篇的引申，主要介紹panic、recover的底層分析，如果沒有讀過上一篇文章，可以先去讀一下在看這篇。
總共分3部分講解：
1 panic
2 defer panic
3 defer panic recover
=======================
環(huán)境：go version go1.12.5 linux/amd64
1 panic
golang中的異?？偣卜譃?中：
- 編譯器捕獲的
- 直接手動panic
- golang捕獲的
- 系統(tǒng)捕獲的
編譯器捕獲的
1/0 我們知道被除數(shù)是不能等于0的，所以這種錯誤是編譯不過去的，會提示：
./main.go:7:8: division by zero
直接手動panic
示例代碼：
package main
func main() {
panic("panic error！！")
}
編譯成匯編代碼看panic函數(shù)會指向底層哪個函數(shù)：
go tool compile -S main.go > main.s
0x0034 00052 (main.go:4) CALL runtime.gopanic(SB)
查看gopanic(SB)實(shí)現(xiàn)，先粗略看一下代碼的含義一些解釋在代碼中已經(jīng)注解：
func gopanic(e interface{}) {
gp := getg() //獲取當(dāng)前的g
....省略不重要的
var p _panic //_panic原型
p.arg = e //將panic參數(shù)存入arg參數(shù)
p.link = gp._panic //將p.link綁定到當(dāng)前的g的_panic上。
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p))) //將p綁定到g的鏈表頭。
atomic.Xadd(&runningPanicDefers, 1)
for {
d := gp._defer
if d == nil {
break
}
if d.started {
if d._panic != nil {
d._panic.aborted = true
}
d._panic = nil
d.fn = nil
gp._defer = d.link
freedefer(d)
continue
}
d.started = true
d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))//將p綁定到g的鏈表頭。
p.argp = unsafe.Pointer(getargp(0))
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz)) //調(diào)用g上的defer(源程序中如果沒有defer函數(shù)，編譯器會生成一個并綁定到g._defer上)
p.argp = nil
if gp._defer != d {
throw("bad defer entry in panic")
}
//脫鏈
d._panic = nil
d.fn = nil
gp._defer = d.link
pc := d.pc
sp := unsafe.Pointer(d.sp) // must be pointer so it gets adjusted during stack copy
freedefer(d)
if p.recovered { //先忽略講到recover時候在說
.....
}
}
preprintpanics(gp._panic)
//循環(huán)打印panic
fatalpanic(gp._panic) // should not return
*(*int)(nil) = 0 // not reached
}
我們發(fā)現(xiàn)panic的原型是_panic,去看一下定義：
type _panic struct {
argp unsafe.Pointer // pointer to arguments of deferred call run during panic; cannot move - known to liblink
arg interface{} // argument to panic
link *_panic // link to earlier panic
recovered bool // whether this panic is over
aborted bool // the panic was aborted
}
發(fā)現(xiàn)是個結(jié)構(gòu)體類型，里面的類型我們在調(diào)試代碼的時候在去探究具體的含義。
接下來我們就用gdb跟蹤一下上面的源碼示例。
go build -o main
gdb main
進(jìn)入gdb界面并斷點(diǎn)到panic函數(shù)行見下圖：
按s進(jìn)入到gopanic(interface)中。
發(fā)現(xiàn)這條語句：
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
原來當(dāng)前的gp定義（由于不是講goroutine 這里就不貼gp的原型了）中有_panc字段作為鏈表頭,而_panic結(jié)構(gòu)體中有l(wèi)ink字段。不難看出和defer同理：從goroutine._panic作為頭，然后用_painc.link作為鏈接組成了一個鏈表的數(shù)據(jù)結(jié)構(gòu)。之所以是鏈表是因?yàn)閞ecover到panic時候，recover中也有可能有panic，例如見下方代碼：
if err := recover(); err != nil {
panic("go on panic xitehip")
}
deferd函數(shù)也會繼續(xù)有panic。下方講到recover時候詳細(xì)講解。
執(zhí)行上面的語句此時的鏈表示意結(jié)構(gòu)見下方：
gp._panic => p.link => gp._panic(之前的鏈表頭)
繼續(xù)往下走：
運(yùn)行到reflectcall()函數(shù)，發(fā)現(xiàn)這個函數(shù)總共有5個參數(shù)：
func reflectcall(argtype *_type, fn, arg unsafe.Pointer, argsize uint32, retoffset uint32)
從第二個參數(shù)可知這個是函數(shù)指針，猜測這個reflectcall是調(diào)用我們實(shí)參unsafe.Point(d.fn)的。根據(jù)源碼中的定義 d := gp._defer可知變量d就是上文我們說的g._defer。那馬上有疑問了，這個例子里根本沒有用到defer關(guān)鍵字，就不會調(diào)用deferproc(SB)生成defer。那只有一種可能就是編譯器幫我們做了生成了一個defer函數(shù)然后綁定到了g._defer的鏈表頭上。
繼續(xù)看reflectcall函數(shù)見下圖x：
用disass命令查看一下匯編代碼，綠線處的是即將調(diào)用的reflectcall函數(shù)。紅線處是它的下一條指令，記住它的地址
0x0000000000423025，我們?nèi)タ匆幌聄eflectcall函數(shù)執(zhí)行完的返回值是如何指向到紅線處的指令的。見下方匯編代碼：
//runtime/asm_amd64.s
TEXT ·reflectcall(SB), NOSPLIT, $0-32
MOVLQZX argsize+24(FP), CX
DISPATCH(runtime·call32, 32)
DISPATCH(runtime·call64, 64)
.....
MOVQ $runtime·badreflectcall(SB), AX
JMP AX
//runtime/asm_amd64.s
#define DISPATCH(NAME,MAXSIZE) \
CMPQ CX, $MAXSIZE; \
JA 3(PC); \
MOVQ $NAME(SB), AX; \
JMP AX
//runtime/asm_amd64.s
#define CALLFN(NAME,MAXSIZE) \
TEXT NAME(SB), WRAPPER, $MAXSIZE-32; \
NO_LOCAL_POINTERS; \
/* copy arguments to stack */ \
MOVQ argptr+16(FP), SI; \
MOVLQZX argsize+24(FP), CX; \
MOVQ SP, DI; \
REP;MOVSB; \
/* call function */ \
MOVQ f+8(FP), DX; \
PCDATA $PCDATA_StackMapIndex, $0; \
CALL (DX); \
/* copy return values back */ \
MOVQ argtype+0(FP), DX; \
MOVQ argptr+16(FP), DI; \
MOVLQZX argsize+24(FP), CX; \
MOVLQZX retoffset+28(FP), BX; \
MOVQ SP, SI; \
ADDQ BX, DI; \
ADDQ BX, SI; \
SUBQ BX, CX; \
CALL callRet<>(SB); \
RET
是不是很亂，這些是啥？？看不懂。用gdb跟蹤一下到：
運(yùn)行到下圖：
disass一下看一下CALLFN(. call32, 32)所指向的指令:
綠框處所對應(yīng)的的就是源文件中的代碼：
TEXT callRet<>(SB), NOSPLIT, $32-0
那紅框ret處就是reflectcall的返回。打到斷點(diǎn)到ret處。
執(zhí)行到這里見下圖：
ret的作用是pop 棧頂?shù)絩ip，我們看一下rsp中的內(nèi)容是啥?
0x423025 所指向的內(nèi)容：
p.argp = nil翻譯成匯編代碼就是圖y中的
mov QWROD PTR [rsp+0x58],0x0，就是變量賦值會把值存入棧中而不是寄存器中。
執(zhí)行完d.fn，將d脫鏈：
d._panic = nil
d.fn = nil
gp._defer = d.link
運(yùn)行到：
func fatalpanic(msgs *_panic)
進(jìn)行打印輸出，看一下實(shí)現(xiàn)：
func fatalpanic(msgs *_panic) {
pc := getcallerpc()
sp := getcallersp()
gp := getg()
var docrash bool
systemstack(func() {
if startpanic_m() && msgs != nil {
atomic.Xadd(&runningPanicDefers, -1)
printpanics(msgs)
}
docrash = dopanic_m(gp, pc, sp)
})
if docrash {
crash()
}
systemstack(func() {
exit(2)
})
*(*int)(nil) = 0 // not reached
}
重點(diǎn)看如下函數(shù)：
printpanics(msgs)
實(shí)現(xiàn)：
func printpanics(p *_panic) {
if p.link != nil {
printpanics(p.link)
print("\t")
}
print("panic: ")
printany(p.arg)
if p.recovered {
print(" [recovered]")
}
print("\n")
}
發(fā)現(xiàn)這個是個遞歸調(diào)用，從g._panic鏈表頭開始直到鏈表結(jié)束然后打印出panic信息。
golang捕獲的
例如slice越界，見下方代碼：
package main
import "fmt"
func main() {
arr := []int{1, 2}
arr[2] = 3
fmt.Println(arr)
}
會panic：
panic: runtime error: index out of range
編譯成匯編代碼：go tool compile -S main.go > main.s
0x003c 00060 (main.go:7) CALL runtime.panicindex(SB)
可知調(diào)用了panicindex(SB)
去看一下它的實(shí)現(xiàn)：
func panicindex() {
if hasPrefix(funcname(findfunc(getcallerpc())), "runtime.") {
throw(string(indexError.(errorString)))
}
panicCheckMalloc(indexError)
panic(indexError)
}
發(fā)現(xiàn)最終還是會調(diào)用panic(interface{})這個函數(shù)，然后就是上面所說的手動panic的執(zhí)行流程，在這里不在重復(fù)贅述。
系統(tǒng)捕獲的
比如對只讀內(nèi)存區(qū)賦值操作會引起panic
package main
import "fmt"
func main() {
var pi *int
*pi = 100
fmt.Printf("%v", *pi)
}
會報如下錯誤：
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x488a53]
goroutine 1 [running]:
main.main()
/server/gotest/src/hello/defer/main.go:7 +0x3a
編譯成匯編代碼沒有發(fā)現(xiàn)gopanic入口。因?yàn)樽罱K輸出panic棧的信息，所以肯定調(diào)用了gopanic，給gopanic()打上斷點(diǎn)直接運(yùn)行到這里見下圖：
確實(shí)攔截到了gopanic，看一下它的調(diào)用鏈：
main.main => runtime.sigpanic() => runtime.panicmem() => gopanic()。
那為什么匯編中沒有sigpanic()入口還能調(diào)用這個函數(shù)呢？
看一下
*pi = 100生成的匯編代碼：
劃紅線處：test BYTE PTR [ax], al 由于ax=0x0所以BYTE PTR [ax]是獲取不到0x0的內(nèi)存的。這樣cpu執(zhí)行這條語句的時候會進(jìn)入內(nèi)核態(tài)保存0x488b1a到寄存器，內(nèi)核態(tài)發(fā)送消息給go進(jìn)程，go處理函數(shù)將0x488b1a所指向的內(nèi)容換成go啟動時事先注冊號的函數(shù)作為指令入口，回到內(nèi)核態(tài)執(zhí)行0x488b1a -> 注冊函數(shù)的指令。具體的調(diào)用鏈在這里就不深究了重點(diǎn)還是panic，recover。
2 defer panic
2.1示例：
package main
import "fmt"
func main() {
defer fmt.Println("d1")
defer fmt.Println("d2")
panic("panic error")
}
輸出：
d2
d1
panic error
如下核心代碼：
//runtime/panic.go
func gopanic(e interface{}) {
for {
...//獲取goroutine表頭deferd
//執(zhí)行表頭的deferd
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
...//將表頭的deferd拖鏈，將下一個deferd綁定到表頭
}
...
fatalpanic(gp._panic) // 運(yùn)行遞歸調(diào)用gp._panic鏈表上的panic
...
}
從上面代碼可知，gopanic先遍歷deferd鏈在遍歷panic鏈，所以panic error最后輸出。
2.2示例：
輸出：
d2
d1
panic: panic error
panic: panic error2
根據(jù)示例2.1 函數(shù)gopanic()可知函數(shù)的調(diào)用鏈見下面調(diào)用關(guān)系：
第14行panic -> gopanic() -> reflectcall -> 第12行defer -> reflectcall -> 第8行defer -> 第9行panic -> gopanic -> reflectcall -> 繼續(xù)執(zhí)行deferd鏈上的也就是第6行defer -> fatalpanic(里面子函數(shù)printpanics()遞歸調(diào)用g._panic鏈)。
3 defer panic recover
下面介紹的是recover的執(zhí)行過程，先看下方示例代碼：
package main
import "fmt"
func main() {
re()
fmt.Println("After recovery!")
}
func re() {
defer func() {
if err := recover(); err != nil {
fmt.Println("err:", err)
}
}()
panic("panic error1")
}
輸出：
err: panic error1
After recovery!
recover()的作用是捕獲異常之后讓程序正常往下執(zhí)行而不會退出。這個例子里re()函數(shù)里有了異常，并且被捕獲然后執(zhí)行了re()下面的代碼輸出'After recovery'。
那為什么執(zhí)行完recover()之后會跳轉(zhuǎn)到輸出行執(zhí)行呢？
從匯編角度考慮：執(zhí)行完re()之后要想保證繼續(xù)往下執(zhí)行，首先要把下一行的入口地址存起來，然后recover()之后再去取回來，放到rip指令寄存器中這樣才可以向下執(zhí)行。
在re()里除了deferd函數(shù)還有有panic()這行，那很明顯它的內(nèi)部實(shí)現(xiàn)里會有相關(guān)實(shí)現(xiàn)，繼續(xù)分析recover的實(shí)現(xiàn)和panic內(nèi)部的相關(guān)實(shí)現(xiàn)。
匯編查看recover()：go tool compile -S main.go
發(fā)現(xiàn)gorecover(SB),猜測是recover()的實(shí)現(xiàn):
0x002a 00042 (main.go:13) CALL runtime.gorecover(SB)
在recover()行打斷點(diǎn),發(fā)現(xiàn)確實(shí)執(zhí)行了gorecover(SB)函數(shù)，實(shí)現(xiàn)如下：
func gorecover(argp uintptr) interface{} {
gp := getg()
p := gp._panic
if p != nil && !p.recovered && argp == uintptr(p.argp) {
p.recovered = true
return p.arg
}
return nil
}
從以上代碼可知gorecover(uintptr)只是把當(dāng)前goroutine的_panic.recovered 設(shè)置為true，然后返回之前panic函數(shù)設(shè)置的參數(shù)(err)給調(diào)用方。其實(shí)就是將當(dāng)前的g._panic設(shè)置個標(biāo)致，告訴以后的程序說我已經(jīng)被捕獲到了。
這個有recover()的deferd函數(shù)執(zhí)行完之后會返回到上面提到的gopanic(interface{})函數(shù)中的reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))下一行繼續(xù)往下執(zhí)行。
見下方代碼：
func gopanic(e interfac{}) {
.......
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
//往下看：
p.argp = nil
if gp._defer != d {
throw("bad defer entry in panic")
}
//執(zhí)行完defered函數(shù)之后脫鏈
d._panic = nil
d.fn = nil
gp._defer = d.link
pc := d.pc //deferproc()函數(shù)中存入的放回值地址
sp := unsafe.Pointer(d.sp) //
freedefer(d)
if p.recovered {//執(zhí)行了gorecover()函數(shù)之后p.recovered == true
atomic.Xadd(&runningPanicDefers, -1)
gp._panic = p.link
for gp._panic != nil && gp._panic.aborted {
gp._panic = gp._panic.link
}
if gp._panic == nil { // must be done with signal
gp.sig = 0
}
gp.sigcode0 = uintptr(sp)
gp.sigcode1 = pc //pc恢復(fù)棧作用。
mcall(recovery)
throw("recovery failed") // mcall should not return
}
......
}
看一下這行代碼：
pc := d.pc
pc是什么呢？它是上篇文章中提到的deferproc()函數(shù)中存入的，見下方代碼：
func deferproc(siz int32, fn *funcval) { // arguments of fn follow fn
...
callerpc := getcallerpc()
d := newdefer(siz)
if d._panic != nil {
throw("deferproc: d.panic != nil after newdefer")
}
d.fn = fn
d.pc = callerpc
....
我們在下方截圖的第12行打一斷點(diǎn)來看一下pc中到底是啥?？匆幌戮G框中的指令：
defer關(guān)鍵字會翻譯成call runtime.deferproc那它下方綠框中的是runtime.deferproc后面的指令是編譯器生成的（也可以這么理解，defer關(guān)鍵字會讓編譯器生成deferproc函數(shù)指令及后面一堆指令）第一行：
test eax, eax的地址是0x4872d5稍后會再次說到這個指令及地址。
繼續(xù)斷點(diǎn)執(zhí)行到d.pc = callerpc之后，我們看一下d.pc到底是什么值，見下圖：
0x4872d5這不是剛剛說的上圖綠框處 test eax, eax的指令地址嗎。帶著疑問繼續(xù)往下看。
從上面gorecover(uintptr)函數(shù)代碼可知 p.recoverd == true 所以gopanic()中會執(zhí)行到if p.recovered {里，我們著重看兩行代碼：
gp.sigcode1 = pc
將pc就是deferproc()函數(shù)的返回值賦值給gp.sigcode1，為返回到正常流程做準(zhǔn)備。
mcall(recovery)
其中的mcall先不看,先看recovery函數(shù)作用,見下方實(shí)現(xiàn)：
func recovery(gp *g) {
// Info about defer passed in G struct.
sp := gp.sigcode0
pc := gp.sigcode1
// d's arguments need to be in the stack.
if sp != 0 && (sp < gp.stack.lo || gp.stack.hi < sp) {
print("recover: ", hex(sp), " not in [", hex(gp.stack.lo), ", ", hex(gp.stack.hi), "]\n")
throw("bad recovery")
}
// Make the deferproc for this d return again,
// this time returning 1. The calling function will
// jump to the standard return epilogue.
gp.sched.sp = sp
gp.sched.pc = pc
gp.sched.lr = 0
gp.sched.ret = 1
gogo(&gp.sched)
}
recovery(*g) 主要是gp.sched賦值。其中pc是當(dāng)前deferproc函數(shù)的返回地址。我們再看一下gogo(&gp.sched)函數(shù)實(shí)現(xiàn)，因?yàn)間ogo函數(shù)是用匯編實(shí)現(xiàn)的所以用gdb跟蹤是最方便的見下方代碼：
TEXT runtime·gogo(SB), NOSPLIT, $16-8
MOVQ buf+0(FP), BX // gobuf
MOVQ gobuf_g(BX), DX
MOVQ 0(DX), CX // make sure g != nil
get_tls(CX)
MOVQ DX, g(CX)
MOVQ gobuf_sp(BX), SP // restore SP
MOVQ gobuf_ret(BX), AX
MOVQ gobuf_ctxt(BX), DX
MOVQ gobuf_bp(BX), BP
MOVQ $0, gobuf_sp(BX) // clear to help garbage collector
MOVQ $0, gobuf_ret(BX)
MOVQ $0, gobuf_ctxt(BX)
MOVQ $0, gobuf_bp(BX)
MOVQ gobuf_pc(BX), BX
JMP BX
著重看2行代碼:
MOVQ gobuf_ret(BX), AX
AX從某個值變成了1，這個指令的偏移數(shù)量是gobuf_ret,其中的ret不就是返回的意思嗎，見下圖。
再看最后一條指令：
JMP BX
看一下BX到底是啥：
綠框處就是BX的值，也就是要jmp到這個地址處執(zhí)行，這個地址眼熟嗎，不就是剛提到的
0x4872d5嗎，對應(yīng)的指令是test eax,eax。再重看一下這個圖：
test eax, eax
jne 0x4872f9
的意思是如果eax不等于0就跳轉(zhuǎn)到這個地址否則就去執(zhí)行綠框處第三行的正常流程。因?yàn)閑ax已經(jīng)不等0了，所以就會跳轉(zhuǎn)到0x4872f9這個地址處，跟蹤一下這個地址指向的是哪里，見下圖:
原來它調(diào)用了
runtime.deferreturn()函數(shù),見下圖。
執(zhí)行到這里。
sp := getcallersp()
sp是調(diào)用者的sp。就是即將調(diào)用defer func() {時的sp。
d.sp 是調(diào)用鏈上第二個defer，因?yàn)榈谝粋€deferd已經(jīng)脫鏈。
顯然這兩個不相等，所以return了，具體return底層到底是如何將re()的返回地址返回的就不在跟蹤了。然后執(zhí)行到了下放的入口地址處：
fmt.Println("After recovery!")
整個流程，參看下圖代碼然后解釋：
call re() => 將re()返回值壓棧到棧頂 => 執(zhí)行12行defer函數(shù) => 執(zhí)行deferproc():將deferproc返回值存入pc，調(diào)用者(re())棧頂存入到sp,將defered函數(shù)加入到鏈表頭，返回0（return0函數(shù)作用是將ax設(shè)為0） => 返回到下方代碼test eax eax處 => 由于ax=0繼續(xù)運(yùn)行到17行的panic() =>gopanic() => 調(diào)用reflectcall():執(zhí)行deferd函數(shù) => 執(zhí)行recovery():將recoverd標(biāo)志位設(shè)為1 => mcall(recovery) => gogo():ax設(shè)為1，跳轉(zhuǎn)到pc處 => 再一次跳轉(zhuǎn)到test eax, eax :由于ax=1 => 跳轉(zhuǎn)到deferreturn()函數(shù):callersp !=d.sp，這里的d.sp中的d其實(shí)已經(jīng)是是g上面默認(rèn)帶的_defer了，所以不等 => return 獲取re()的返回地址pop到rip處 => cpu執(zhí)行其返回值 => 輸出'After recovery'
...
//defer函數(shù) =>deferproc
0x00000000004872d0 <+48>: call 0x426c00 <runtime.deferproc>
0x00000000004872d5 <+53>: test eax,eax
0x00000000004872d7 <+55>: jne 0x4872f9 <main.re+89>
0x00000000004872d9 <+57>: jmp 0x4872db <main.re+59>
0x00000000004872db <+59>: lea rax,[rip+0x111be] # 0x4984a0
0x00000000004872e2 <+66>: mov QWORD PTR [rsp],rax
0x00000000004872e6 <+70>: lea rax,[rip+0x48643]
0x00000000004872ed <+77>: mov QWORD PTR [rsp+0x8],rax
//panic() => gopanic
0x00000000004872f2 <+82>: call 0x427880 <runtime.gopanic>
...
recover()的核心其實(shí)就是defer函數(shù)生成的匯編指令：判斷跳轉(zhuǎn)區(qū)分正常流程還是獲取返回值流程。見上方匯編代碼。
機(jī)器指令是從上往下執(zhí)行，正常流程是執(zhí)行完deferproc之后再執(zhí)行panic()生成的gopanic()。獲取返回值流程必然需要跳轉(zhuǎn)到某處獲取，而golang的設(shè)計者放到了deferreturn()函數(shù)中所以最終要跳到這里來。
留個疑問下方代碼如何輸出，為什么？
package main
import "fmt"
func main() {
re()
fmt.Println("After recovery!")
}
func re() {
defer func() {
if err := recover(); err != nil {
fmt.Println("Recover again:", err)
}
}()
defer func() {
if err := recover(); err != nil {
switch v := err.(type) {
case string:
panic(string(v))
}
}
}()
panic("start panic")
}
