面试题：Go panic与recover机制的底层原理及优化

1. panic 和 recover 底层实现原理

栈的处理

panic：当 panic 发生时，Go 运行时会开始展开（unwind）调用栈。它从触发 panic 的函数开始，逐步向上遍历调用栈，依次调用每个函数的延迟函数（defer）。在这个过程中，栈帧并不会立即被销毁，而是保留其状态以便后续可能的恢复操作。例如：

package main

import "fmt"

func f1() {
    fmt.Println("f1 start")
    defer fmt.Println("f1 defer")
    f2()
    fmt.Println("f1 end")
}

func f2() {
    fmt.Println("f2 start")
    defer fmt.Println("f2 defer")
    panic("f2 panic")
    fmt.Println("f2 end")
}

func main() {
    f1()
}

在上述代码中，f2 触发 panic 后，会先执行 f2 的延迟函数 fmt.Println("f2 defer")，然后继续向上展开调用栈，执行 f1 的延迟函数 fmt.Println("f1 defer")。

recover：recover 只能在延迟函数（defer）中生效。当 recover 被调用时，它会停止栈的展开，并返回传递给 panic 的值。如果当前没有 panic 正在进行，recover 将返回 nil。它通过获取当前栈帧的状态信息来判断是否有 panic 发生。

运行时的状态变化

panic：当 panic 发生时，运行时系统会将当前协程的状态标记为 panic 状态。这个状态下，协程会停止正常的执行流程，开始执行延迟函数并展开调用栈。同时，运行时会记录 panic 的值，以便后续 recover 可以获取。
recover：调用 recover 成功后，运行时会将协程从 panic 状态恢复到正常状态，使得协程可以继续执行延迟函数之后的代码（如果有）。如果 recover 调用失败（即当前没有 panic），协程将继续按照展开调用栈的流程执行，直至整个协程终止。

2. 高并发场景下的优化

优化建议

局部处理：尽量在每个独立的逻辑单元内部处理 panic，避免 panic 扩散到整个程序。这样可以防止一个协程的 panic 影响其他协程的正常运行。例如，在一个 HTTP 服务中，每个请求处理函数应该独立处理 panic，防止一个请求的错误导致整个服务崩溃。
减少不必要的 panic：在可能发生错误的地方，优先使用常规的错误处理机制，只有在真正遇到不可恢复的错误时才使用 panic。例如，文件读取失败可以返回一个错误值让调用者处理，而不是直接 panic。
控制资源释放：在延迟函数中，确保资源的正确释放。高并发场景下，资源竞争可能导致资源释放失败，所以要使用合适的同步机制（如互斥锁）来保证资源的安全释放。

代码示例

package main

import (
    "fmt"
    "sync"
)

func worker(id int, wg *sync.WaitGroup) {
    defer wg.Done()
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("Worker %d recovered from panic: %v\n", id, r)
        }
    }()

    // 模拟可能发生 panic 的操作
    if id == 2 {
        panic("Simulated panic in worker 2")
    }
    fmt.Printf("Worker %d is working\n", id)
}

func main() {
    var wg sync.WaitGroup
    for i := 1; i <= 3; i++ {
        wg.Add(1)
        go worker(i, &wg)
    }
    wg.Wait()
    fmt.Println("All workers completed")
}

在上述代码中，每个 worker 协程都有自己的延迟函数来处理 panic，这样即使某个协程发生 panic，其他协程仍然可以继续执行，提高了程序的稳定性。同时，在 main 函数中使用 sync.WaitGroup 来等待所有协程完成，确保程序不会提前退出。