- panic 能够改变程序的控制流，调用 panic 后会立刻停止执行当前函数的剩余代码，并在当前 goroutine 中递归执行调用方的 defer。
- recover 可以中止 panic 造成的程序崩溃。它是一个只能在 defer 中发挥作用的函数，在其他作用域中调用不会发挥作用。
相关数据结构:
// A _panic holds information about an active panic.
//
// A _panic value must only ever live on the stack.
//
// The argp and link fields are stack pointers, but don't need special
// handling during stack growth: because they are pointer-typed and
// _panic values only live on the stack, regular stack pointer
// adjustment takes care of them.
type _panic struct {argp unsafe.Pointer // pointer to arguments of deferred call run during panic; cannot move - known to liblinkarg any // argument to paniclink *_panic // link to earlier panicpc uintptr // where to return to in runtime if this panic is bypassedsp unsafe.Pointer // where to return to in runtime if this panic is bypassedrecovered bool // whether this panic is overaborted bool // the panic was abortedgoexit bool
}
程序崩溃
- 创建新的 panic函数并添加到所在 goroutine 的 _panic 链表的最前面。
- 在循环中不断从当前 goroutine 的 _defer 中链表获取 defer函数并调用执行。
- 调用 runtime.fatalpanic 中止整个程序。
runtime.fatalpanic 实现了无法被恢复的程序崩溃： - 它在中止程序之前会通过 runtime.printpanics 打印出全部的 panic 消息以及调用时传入的参数。
- 打印崩溃消息后会调用 runtime.exit 退出当前程序并返回错误码 2，程序的正常退出也是通过 runtime.exit 实现的。
崩溃恢复
- recovered 设置为 true。
- 重置 pc，sp 寄存器，重新把 Goroutine 投递到调度队列中。
总结：
- panic() 会退出进程，是因为调用了 exit 的系统调用。
- recover() 并不是说只能在 defer 里面调用，而是只能在 defer 函数中才能生效，只有在 defer 函数里面，才有可能遇到 _panic 结构。
- recover() 所在的 defer 函数必须和 panic 都是挂在同一个 goroutine 上，不能跨协程，因为 gopanic 只会执行当前 goroutine 的延迟函数。
- panic 的恢复，就是重置 pc 寄存器，直接跳转程序执行的指令，跳转到原本 defer 函数执行完该跳转的位置（deferreturn 执行），从 gopanic 函数中跳出，不再回来，自然就不会再 fatalpanic 。
)
)
