面试题：Go 的 recover 在并发编程中的应用与陷阱

Question

在 Go 的并发编程场景下，一个 goroutine 中发生了 panic，如何通过 recover 机制确保整个程序不会崩溃，并且能合理处理该 panic 信息。同时阐述在这种场景下使用 recover 可能会遇到哪些陷阱及如何避免。

Answer 1

确保程序不崩溃并处理 panic 信息

在 Go 语言中，recover 只能在 defer 函数中使用。要确保整个程序不会因某个 goroutine 中的 panic 而崩溃，并合理处理该 panic 信息，可以按照以下步骤进行：

package main

import (
    "fmt"
)

func worker() {
    defer func() {
        if r := recover(); r != nil {
            // 处理 panic 信息
            fmt.Println("Recovered from panic:", r)
        }
    }()

    // 模拟可能发生 panic 的操作
    panic("Something went wrong")
}

func main() {
    go worker()
    // 主 goroutine 执行其他逻辑，防止程序立即退出
    select {}
}

在上述代码中：

1. 在 worker 函数中使用 defer 语句注册一个匿名函数。
2. 在匿名函数中使用 recover 来捕获 panic。如果 recover 返回的值不为 nil，则表示发生了 panic，可以对该值进行处理。

使用 recover 可能遇到的陷阱及避免方法

1. 作用域问题
   • 陷阱：recover 只能在当前 goroutine 的 defer 函数中起作用。如果在其他 goroutine 或 defer 函数外部调用 recover，它将始终返回 nil。
   • 避免方法：确保 recover 在发生 panic 的 goroutine 的 defer 函数中调用。例如，不要在 defer 函数调用的其他函数中尝试调用 recover，除非将 recover 作为参数传递进去并在合适位置调用。
2. 多层 defer 嵌套
   • 陷阱：如果有多层 defer 嵌套，recover 只会捕获最内层 defer 对应的 panic。外层 defer 函数中的 recover 不会捕获内层 defer 已经处理过的 panic。
   • 避免方法：尽量简化 defer 嵌套结构，如果无法避免，确保在最内层 defer 中正确处理 panic，或者在每层 defer 中都进行适当的检查和处理，防止 panic 未被完全处理。
3. 并发场景下的错误传递
   • 陷阱：在并发场景中，如果一个 goroutine 发生 panic 并被 recover，其他 goroutine 可能并不知道这个错误，从而导致数据不一致或程序逻辑错误。
   • 避免方法：可以使用通道（channel）来传递错误信息，以便其他 goroutine 能够感知并做出相应处理。例如，在 recover 后将错误信息发送到一个共享的通道中，其他 goroutine 监听该通道并进行相应处理。

package main

import (
    "fmt"
)

func worker(errCh chan<- error) {
    defer func() {
        if r := recover(); r != nil {
            errCh <- fmt.Errorf("Recovered from panic: %v", r)
        }
    }()

    panic("Something went wrong")
}

func main() {
    errCh := make(chan error)
    go worker(errCh)

    go func() {
        err := <-errCh
        fmt.Println("Received error:", err)
    }()

    select {}
}

通过这种方式，可以在并发场景下更好地处理错误信息。