附录 B：Goroutine 与 panic、recover 的小问题
在 Go 语言中，goroutine、panic、recover 是人尽皆知关键字，几乎在每一个项目中，你必定会主动地使用到它。即使你不主动使用，你也无法避免你所使用的标准库、第三方外部依赖模块使用它。
虽然它们在程序中非常常见，但依然会有许多刚入门的开发者在初次使用时遇到小 “坑”，并对这个处理结果都表现出很震惊，接下来在本文中我们将对这一个小 ”坑“ 进行说明。
B.1 思考问题
func main() {
go func() {
panic("煎鱼焦了")
}()
log.Println("Go 语言编程之旅：一起用 Go 做项目")
}
我们思考一下上述程序，其输出的结果是书名，还是会因为 “煎鱼焦了” 而直接中断程序，结果如下：
panic: 煎鱼焦了
goroutine 6 [running]:
main.main.func1()
/Users/eddycjy/go/src/github.com/eddycjy/awesomeProject/main.go:7 +0x39
created by main.main
/Users/eddycjy/go/src/github.com/eddycjy/awesomeProject/main.go:6 +0x35
最终的结果是程序因为 “煎鱼焦了” 而中断运行，这时候经常会有人提出一个疑问，就是我的 panic 语句是写在子协程（goroutine）里的，怎么会影响外面的主协程（main goroutine）呢，它们不是应该相互隔离的吗，怎么会互相影响呢？
B.2 如何解决
针对这个现象，我们要如何解决呢，首先对于 panic 事件，大家都知道要使用组合方法 recover 来进行处理，如下：
func main() {
go func() {
if e := recover(); e != nil {
log.Printf("recover: %v", e)
}
panic("煎鱼焦了")
}()
log.Println("Go 语言编程之旅：一起用 Go 做项目")
time.Sleep(time.Second)
}
但是单单使用 recover，依旧会输出 “煎鱼焦了”，并且程序中断，正确的方式如下：
func main() {
go func() {
defer func() {
if e := recover(); e != nil {
log.Printf("recover: %v", e)
}
}()
panic("煎鱼焦了")
}()
log.Println("Go 语言编程之旅：一起用 Go 做项目")
}
实际上 recover 要与 defer 联用，并且不跨协程（goroutine），才能够真正的拦截到 panic 事件，其最终的输出结果如下：
Go 语言编程之旅：一起用 Go 做项目
recover: 煎鱼焦了
B.3 为什么要 defer 才能 recover
从前文中我们可以知道，除了 panic、recover 以外，还必须要有 defer 关键字，缺一不可，那么与 defer 又有什么关系呢，为什么必须要有 defer 后 recover 才能起作用？
B.3.1 快速了解 panic
panic 是 Go 语言中的一个内置函数，可以停止程序的控制流，改变其流转，并且触发恐慌事件。而 recover 也是一个内置函数，但其功能与 panic 相对，recover 可以让程序重新获取恐慌后的程序控制权，但是必须在 defer 中 recover 才会生效。
而 panic 的一切，都基于一个 _panic 基础单元，基本结构如下：
type _panic struct {
argp unsafe.Pointer
arg interface{}
link *_panic
pc uintptr
sp unsafe.Pointer
recovered bool
aborted bool
goexit bool
}
在我们每执行一次 panic 语句时，都会创建一个 _panic。它包含了一些基础的字段用于存储当前的 panic 调用情况，涉及的字段如下：
- argp：指向
defer延迟调用的参数的指针。 - arg：
panic的原因，也就是调用panic时传入的参数。 - link：指向上一个调用的
_panic。 - pc：程序计数器，有时称为指令指针（IP），线程利用它来跟踪下一个要执行的指令。在大多数处理器中，PC 指向的是下一条指令，而不是当前指令。
- sp：函数栈指针寄存器，一般指向当前函数栈的栈顶。
- recovered：
panic是否已经被处理，也就是是否被recover。 - aborted：
panic是否被中止。 - goexit：是否调用
runtime.Goexit方法中止过主goroutine及所属的goroutine。
通过查看 link 字段，可得知 panic 的基本单元是一个链表的数据结构，如下图：
B.3.2 快速了解 defer
defer 是 Go 语言中的一个内置函数，defer 方法所注册的对应事件会在函数/方法结束后执行，常用于关闭各类资源以及兜底操作。而相对于 panic 的基础单元 _panic 结构体，defer 也有 _defer 结构体，基本结构如下：
type _defer struct {
siz int32
started bool
sp uintptr
pc uintptr
fn *funcval
_panic *_panic
link *_defer
...
}
type funcval struct {
fn uintptr
// variable-size, fn-specific data here
}
- siz：所有传入参数的总大小。
- started：该
defer是否已经执行过。 - sp：函数栈指针寄存器，在
_panic时已介绍。 - pc：程序计数器，在
_panic时已介绍。 - fn：指向传入的函数地址和参数。
_panic：指向_panic链表。- link：指向
_defer链表。
通过查看 _panic 和 link 字段，我们可得知 defer 也是同时挂载着 panic 信息的，如下：
B.3.3 recover 是如何和 defer 搭上关系的
刚刚我们一直看到的是 defer 和 panic 存在的一定的关联关系，那么 recover 又和它们是怎么产生关系的呢，为什么不用 defer，recover 就无法生效？
为了解答这些问题，我们要回到一切的起源 panic 才能知晓一二，panic 关键字的具体代码实现如下：
func gopanic(e interface{}) {
gp := getg()
...
var p _panic
p.arg = e
p.link = gp._panic
gp._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
for {
d := gp._defer
if d == nil {
break
}
// defer...
...
d._panic = (*_panic)(noescape(unsafe.Pointer(&p)))
p.argp = unsafe.Pointer(getargp(0))
reflectcall(nil, unsafe.Pointer(d.fn), deferArgs(d), uint32(d.siz), uint32(d.siz))
p.argp = nil
// recover...
if p.recovered {
...
mcall(recovery)
throw("recovery failed") // mcall should not return
}
}
preprintpanics(gp._panic)
fatalpanic(gp._panic) // should not return
*(*int)(nil) = 0 // not reached
}
通过分析上述代码，我们可以大致了解到其处理过程：
- 获取指向当前
Goroutine的指针。 - 初始化一个
panic的基本单位_panic用作后续的操作。 - 获取当前
Goroutine上挂载的_defer。 - 若当前存在
defer调用，则调用reflectcall方法去执行先前defer中延迟执行的代码，若在执行过程中需要运行recover将会调用gorecover方法。 - 中断程序结束前，调用
preprintpanics方法打印出所涉及的panic消息。 - 最后调用
fatalpanic中止应用程序，实际是执行exit(2)进行最终退出行为的。
再回到我们的问题 “recover 是如何和 defer 搭上关系的”，我们可得知在调用 panic 方法后，runtime.gopanic 方法实际上处理的是当前 Goroutine 上所挂载的 ._panic 链表（所以无法对其他 Goroutine 的异常事件响应），然后会对其所属的 defer 链表和 recover 进行检测并处理，最后调用退出命令中止应用程序。
从代码实现上来讲，因为 panic 会触发延迟调用（defer），那么假设当前 Goroutine 不存在 defer 的话，就会直接跳出，也就无法进行 recover 了，也就是在 panic 时 Go 只会在 defer 中对 reocver 进行检测。
而从设计实现上来讲，这也是相对合理的，因为我们无法执行到哪都写一个 recover，很多错误你是无法预料在哪里发生的，又是如何发生的。
B.4 recover 是万能的吗
想太多了，有了 recover 并不代表你能够捕获到所有的错误。
就在某一天，你的程序还在线上环境运行着，突然就挂了，刚好这程序在容器里运行，它反复的重启，但每次都不是马上出问题，都是运行了一段时间后出现了宕机，你一脸懵逼，难道有泄露了？
但不过这个程序非常简短，就是个简单的并发清洗、组装数据，你查看到核心（伪）代码如下：
func main() {
m := make(map[int]string)
for i := 0; i < 10; i++ {
go func() {
defer func() {
if e := recover(); e != nil {
log.Printf("recover: %v", e)
}
}()
m[i] = "Go 语言编程之旅：一起用 Go 做项目"
}()
}
// do something...
}
你心想，我都听着煎鱼说的把 recover 都加进 goroutine 里了，怎么还会出现无法捕获的错误，还导致程序挂了，难道煎鱼教的是错的吗？
同时你查看了对应的控制台日志，其关键信息如下：
fatal error: concurrent map writes
goroutine 21 [running]:
runtime.throw(0x10d2c3b, 0x15)
/usr/local/Cellar/go/1.14/libexec/src/runtime/panic.go:1112 +0x72 fp=0xc000029f50 sp=0xc000029f20 pc=0x102e892
runtime.mapassign_fast64(0x10b58e0, 0xc000090180, 0x8, 0x0)
/usr/local/Cellar/go/1.14/libexec/src/runtime/map_fast64.go:101 +0x323 fp=0xc000029f90 sp=0xc000029f50 pc=0x100f733
通过错误信息我们可得知这是一个很常见的问题，就是并发写入 map 导致的致命错误，但是为什么不可以被 recover 捕获到呢，我们关注到 runtime.throw 方法，代码如下：
func throw(s string) {
systemstack(func() {
print("fatal error: ", s, "\n")
})
gp := getg()
if gp.m.throwing == 0 {
gp.m.throwing = 1
}
fatalthrow()
*(*int)(nil) = 0 // not reached
}
关键的中断步骤在于 fatalthrow 方法，如下：
func fatalthrow() {
...
systemstack(func() {
...
exit(2)
})
*(*int)(nil) = 0 // not reached
}
我们可以看到该方法是直接通过调用 exit 方法进行中断的，而实际上在 Go 语言中，是存在着这些无法恢复的 ”恐慌“，例如像是 fatalthrow、fatalpanic 等等方法，因此自然而然使用 recover 就无法捕获到了，因为它是直接退出程序，结果是中断程序。
因此 recover 并非万能，它只针对用户态下的 panic 关键字有效。
B.5 小结
在本文中我们针对 panic 的常见问题，基于 goroutine、panic、recover 做了初步的分析，而在解析 recover 相关行为时，我们发现其与 defer 是存在关联关系的，其四者本质上是一个互相联动的关系。
在最后我们可以总结出如下使用细节：
panic只能触发当前Goroutine的defer调用，在defer调用中如果存在recover，那么就能够处理其所抛出的恐慌事件。但是需要注意的是在其它Goroutine中的defer是对其没有用的，并不支持跨协程（goroutine），需要分清楚。- 想捕获/处理
panic所造成的恐慌，recover必须与defer配套使用，否则无效。 - 在 Go 语言中，是存在着无法处理的致命错误方法的，例如：
fatalthrow、fatalpanic方法，一般会在并发写入map等等处理时抛出，需要谨慎。
