go panic和recover

• 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 liblink
   arg       any            // argument to panic
   link      *_panic        // link to earlier panic
   pc        uintptr        // where to return to in runtime if this panic is bypassed
   sp        unsafe.Pointer // where to return to in runtime if this panic is bypassed
   recovered bool           // whether this panic is over
   aborted   bool           // the panic was aborted
   goexit    bool
}

程序崩溃

1. 创建新的 panic函数并添加到所在 goroutine 的 _panic 链表的最前面。
2. 在循环中不断从当前 goroutine 的 _defer 中链表获取 defer函数并调用执行。
3. 调用 runtime.fatalpanic 中止整个程序。
   runtime.fatalpanic 实现了无法被恢复的程序崩溃：
4. 它在中止程序之前会通过 runtime.printpanics 打印出全部的 panic 消息以及调用时传入的参数。
5. 打印崩溃消息后会调用 runtime.exit 退出当前程序并返回错误码 2，程序的正常退出也是通过 runtime.exit 实现的。

崩溃恢复

1. recovered 设置为 true。
2. 重置 pc，sp 寄存器，重新把 Goroutine 投递到调度队列中。

总结：

1. panic() 会退出进程，是因为调用了 exit 的系统调用。
2. recover() 并不是说只能在 defer 里面调用，而是只能在 defer 函数中才能生效，只有在 defer 函数里面，才有可能遇到 _panic 结构。
3. recover() 所在的 defer 函数必须和 panic 都是挂在同一个 goroutine 上，不能跨协程，因为 gopanic 只会执行当前 goroutine 的延迟函数。
4. panic 的恢复，就是重置 pc 寄存器，直接跳转程序执行的指令，跳转到原本 defer 函数执行完该跳转的位置（deferreturn 执行），从 gopanic 函数中跳出，不再回来，自然就不会再 fatalpanic 。