【译】Go：程序如何恢复?

原文：https://medium.com/a-journey-with-go/go-how-does-a-program-recover-fbbbf27cc31e

​ 当程序不能正确处理错误时， 会触发 Go 的 panic，比如无效的内存访问。如果错误时意外发生的，并且没有别的方法来处理它，开发人员也可以触发 panic。理解恢复或终止的流程有助于理解程序 panic 的后果。

多个函数帧

关于 panic 和 recover 有很多典型的例子和文档，包括 Go 博客中的 "Defer, Panic, and Recover"。让我们关注一个不同的例子，其中 panic 涉及到多个 defer 函数。下面是例子：

func main() {
  defer println("defer 1")
  
  level1()
}

func level1() {
  defer println("defer func 3")
  defer func() {
    if err := recover(); err != nil {
      println("recovering in progress...")
    }
  }()
  defer println("defer 2")
  level2()
}

func level2() {
  defer println("defer func 4")
  panic("foo")
}

这个程序由三个函数组成， 它们在链中被调用。一旦代码在最后一层 panic，Go将在主函数中运行这些 defer 函数：

在该阶段的中运行的代码没有恢复 panic， 然后 Go 构建父函数并且调用每个函数里的 defer

提醒一下，defer 函数是按照 后进先出（LIFO）的顺序执行的。关于 defer 函数内部信息，我建议你阅读 Go: How Does defer Statement Work?

由于一个其中一个函数可以恢复 panic，所以 Go 需要一种方法来跟踪它并恢复程序的执行。为此，每个 goroutine 都嵌入了一个特殊的属性，指向了代表 panic 的对象

当 panic 发生时，在运行 defer 函数之前创建该对象。然后，恢复 panic 的函数实际上只是返回该对象的信息，并将 panic 标记为已恢复

一旦发现 panic 已经恢复，Go需要继续当前的工作。然而，由于运行时是在 defer 中， 它不知道从哪里恢复，因此，当 panic 被标记为已恢复时，Go保存当前函数的程序计数器和堆栈指针，以便在发生 panic 之后恢复。

我们也可以用 objdump 检查程序计数器代表什么

(e.g. objdump -D my-binary | grep 105acef)

此指令指向函数调用 runtime.deferreturn, 这是由编译器插入到每个函数末尾的指令，该指令运行 deferred 函数。在前面的例子中，它们中的大多数在恢复之前已经运行，因此在返回到调用者之前只有还没被调用的。

Wait Group

理解这个工作流向我们展示了defer函数的重要性，以及如何发挥作用，例如，在处理一组 goroutine 时，在 defer 函数中延迟对 WaitGroup 对象的调用可以防止死锁，这里有一个例子：

func main() {
  var wg sync.WaitGroup
  wg.Add(1)
  
  go func() {
    defer func() {
      if err := recover(); err != nil {
        println(err.(string))
      }
    }()
    p()
    wg.Done()
  }()
  wg.Wait()
}

func p() {
  panic("foo")
}

这个程序会导致死锁，因为 wg.Done 永远不会被调用。将 wg.Done 移动到一个 defer 函数可以确保被调用，程序可以继续执行

Goexit

值得注意的是函数 runtime.Goexit 使用完全相同的工作流。它实际上创建了一个带有特殊标志的 panic 对象，以区别真正的 panic。此标志允许运行时跳过恢复并正确退出，而不是停止程序的执行。