3.panic和recover.md

数据结构

type _panic struct {
	argp      unsafe.Pointer // 指向 defer 调用时参数的指针
	arg       interface{}    // 调用 panic 时传入的参数
	link      *_panic        // 链表
	recovered bool           // 表示当前 runtime._panic 是否被 recover 恢复
	aborted   bool           // 表示当前的 panic 是否被强行终止
	pc        uintptr
	sp        unsafe.Pointer
	goexit    bool
}

panic 实现

编译器会将关键字 panic 转换成 runtime.gopanic，该函数的执行过程包含以下几个步骤：

1. 创建新的 runtime._panic 并添加到所在 Goroutine 的 _panic 链表的最前面；
2. 在循环中不断从当前 Goroutine 的 _defer 中链表获取 runtime._defer 并调用 runtime.reflectcall 运行延迟调用函数；
3. 调用 runtime.fatalpanic 中止当前协程；

func gopanic(e interface{}) {
	gp := getg()
	...
	var p _panic                                         // 创建新的 panic
	p.arg = e
	p.link = gp._panic                                   // 将 G 原本的 panic链表 挂到新建的 panic 后面
	gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))  // 将新建的 panic 链表挂到 G 上

	for { // 遍历处理 G 的 defer 链表
		d := gp._defer
		if d == nil {
			break
		}

		d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))

		reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz)) // 执行 defer 里的函数 d.fn

		d._panic = nil
		d.fn = nil
		gp._defer = d.link

		freedefer(d)
		if p.recovered {
			...
		}
	}

	fatalpanic(gp._panic)
	*(*int)(nil) = 0
}

这段省略了 recover 分支的逻辑，这部分放到下面解析

由于 panic 和 G 是关联的，因此在主协程里的 recover，是无法捕获到子协程里的 panic 的。

另外可以看到发生 panic 时，会遍历处理 G 的 defer 链表，因此使用 defer 进行收尾工作一般来说都是安全的。

recover 实现

编译器会将关键字 recover 转换成 runtime.gorecover：

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 // 当前 Goroutine 没有 panic，那么该函数会直接返回
}

如果当前 Goroutine 没有 panic，那么该函数会直接返回 nil。在正常情况下，它会修改 runtime._panic 的 recovered 字段，runtime.gorecover 函数中并不包含恢复程序的逻辑，程序的恢复是由上面的 runtime.gopanic 函数负责的：

func gopanic(e interface{}) {
	...

	for {
		pc := d.pc                 // 程序计数器 pc
		sp := unsafe.Pointer(d.sp) // 栈指针 sp 

		...
		if p.recovered {
			gp._panic = p.link
			for gp._panic != nil && gp._panic.aborted {
				gp._panic = gp._panic.link
			}
			if gp._panic == nil {
				gp.sig = 0
			}
			gp.sigcode0 = uintptr(sp)
			gp.sigcode1 = pc
			mcall(recovery) // 调用 runtime.recovery 并触发调度
			throw("recovery failed")
		}
	}
	...
}

func recovery(gp *g) {
	sp := gp.sigcode0
	pc := gp.sigcode1

	gp.sched.sp = sp
	gp.sched.pc = pc
	gp.sched.lr = 0
	gp.sched.ret = 1
	gogo(&gp.sched)
}

当我们在调用 defer 关键字时，调用时的栈指针 sp 和程序计数器 pc 就已经存储到了 runtime._defer 结构体中，这里的 runtime.gogo 函数会跳回 defer 关键字调用的位置。

runtime.recovery 在调度过程中会将函数的返回值设置成 1。从 runtime.deferproc 的注释中我们会发现，当 runtime.deferproc 函数的返回值是 1 时，编译器生成的代码会直接跳转到调用方函数返回之前并执行 runtime.deferreturn：

func deferproc(siz int32, fn *funcval) {
	...
	return0() // runtime.deferreturn
}

跳转到 runtime.deferreturn 函数之后，程序就已经从 panic 中恢复了并执行正常的逻辑，而 runtime.gorecover 函数也能从 runtime._panic 结构中取出了调用 panic 时传入的 arg 参数并返回给调用方。

小结

分析程序的崩溃和恢复过程比较棘手，代码不是特别容易理解。我们在本节的最后还是简单总结一下程序崩溃和恢复的过程：

1. 编译器会负责做转换关键字的工作；

   1. 将 panic 和 recover 分别转换成 runtime.gopanic 和 runtime.gorecover；
   2. 将 defer 转换成 runtime.deferproc 函数；
   3. 在调用 defer 的函数末尾调用 runtime.deferreturn 函数；

2. 在运行过程中遇到 runtime.gopanic 方法时，会从 Goroutine 的链表依次取出 runtime._defer 结构体并执行；

3. 如果调用延迟执行函数时遇到了 runtime.gorecover 就会将_panic.recovered 标记成 true 并返回 panic 的参数；

   1. 在这次调用结束之后，runtime.gopanic 会从 runtime._defer 结构体中取出程序计数器 pc 和栈指针 sp 并调用 runtime.recovery 函数进行恢复程序；
   2. runtime.recovery 会根据传入的 pc 和 sp 跳转回 runtime.deferproc；
   3. 编译器自动生成的代码会发现 runtime.deferproc 的返回值不为 0，这时会跳回 runtime.deferreturn 并恢复到正常的执行流程；

4. 如果没有遇到 runtime.gorecover 就会依次遍历所有的 runtime._defer，并在最后调用 runtime.fatalpanic 中止程序、打印 panic 的参数并返回错误码 2；

分析的过程涉及了很多语言底层的知识，源代码阅读起来也比较晦涩，其中充斥着反常规的控制流程，通过程序计数器来回跳转，不过对于我们理解程序的执行流程还是很有帮助。

原文链接

https://draveness.me/golang/docs/part2-foundation/ch05-keyword/golang-panic-recover0