在日常使用 Go 语言开发时，我们经常会遇到各种异常处理场景。许多开发者认为使用recover()可以捕获所有异常，但事实真的如此吗？

fatal error: concurrent map read and map write

这里就来深入探讨一个特别的情况：map的并发读写错误能否被recover捕获。

从一个常见误区说起

很多 Go 语言开发者都有这样的认知：只要使用recover()，就能捕获所有的 panic，保证程序不会崩溃。于是当他们遇到 map 并发读写问题时，可能会写出这样的代码：

defer func() {
    if r := recover(); r != nil {
        fmt.Println("捕获到异常:", r)
    }
}()
// ... 并发操作map的代码

然而，实际情况是：当map发生并发读写时，程序仍然会崩溃，recover 根本不起作用！

为什么 recover 无法捕获 map 并发读写错误？

两种不同的"异常"机制

在 Go 语言中，实际上存在两种导致程序崩溃的机制：

1. 普通Panic：可以通过panic()函数触发，也会由一些运行时错误（如空指针解引用、越界访问等）产生。这种 panic 可以被 recover 捕获。
2. Runtime Throw：这是由 Go 运行时系统触发的致命错误（fatal error），不走 panic/recover 机制，会直接终止进程。

Map 并发读写属于 Runtime Throw

Map 的并发读写错误属于第二种情况—— Runtime Throw，这就是为什么 recover 无法捕获它的根本原因。

当多个 goroutine 同时对同一个已经初始化的map进行读写操作时，Go 运行时会检测到这种并发访问，并抛出 fatal error。这是一种比 panic 更严重的错误，目的是防止数据结构损坏和更严重的内存安全问题。

// 这个例子会导致无法恢复的fatal error
m := make(map[int]int)
go func() {
    for i := 0; i < 1000; i++ {
        m[i] = i // 并发写
    }
}()
go func() {
    for i := 0; i < 1000; i++ {
        _ = m[i] // 并发读
    }
}()

// fatal error: concurrent map read and map write

特殊情况：nil map的并发访问

有趣的是，对于nil map的并发访问行为却有所不同。

从表格可以看出，写入 nil map 会产生普通panic，这种 panic 是可以被 recover 捕获的：

var nilMap map[int]int // nil map

defer func() {
    if r := recover(); r != nil {
        fmt.Println("捕获到panic:", r) // 这里会执行
    }
}()
nilMap[1] = 100 // 这会触发普通panic，可被recover捕获

为什么Go要这样设计？

你可能会问，为什么 Go 语言要这样设计呢？其实这背后有合理的考量。

Map 的并发读写通常意味着严重的设计问题。如果在这种情况下允许 recover，可能会掩盖更深层的 bug，导致数据不一致或其他难以调试的问题。Go 语言的设计哲学是："发现错误尽早暴露"，而不是掩盖它们。

对于确实需要并发访问的场景，Go 提供了两种解决方案：

1. 使用互斥锁（sync.Mutex）保护

var m = make(map[int]int)
var mu sync.Mutex

// 写操作
mu.Lock()
m[key] = value
mu.Unlock()

// 读操作
mu.Lock()
value := m[key]
mu.Unlock()

2. 使用sync.Map（Go 1.9+）

var sm sync.Map

// 写操作
sm.Store(key, value)

// 读操作
if value, ok := sm.Load(key); ok {
    // 使用value
}

sync.Map 更适合读多写少的场景，而在写操作频繁的情况下，使用互斥锁保护的普通 map 可能性能更好。

其他recover无法捕获的错误

除了map并发读写外，还有一些其他错误也是 recover 无法捕获的：

1. 栈溢出（stack overflow）：通常由于无限递归或过大的局部变量导致
2. 内存不足：无法分配请求的内存
3. 其他运行时致命错误：如数据竞争、线程调度问题等

实践建议

基于以上分析，我们在日常开发中应该：

1. 预防优于补救：不要指望用 recover 来处理 map 并发读写问题，而应该在设计阶段就避免它。
2. 明确错误类型：了解哪些错误是可恢复的，哪些是不可恢复的。
3. 合理使用同步机制：根据实际场景选择 sync.Mutex 或 sync.Map 来处理并发 map 访问。
4. 代码审查关注点：在代码审查中特别关注 map 的并发访问情况。

写在最后

recover不能捕获map的并发读写错误，因为这种错误是 Go 运行时抛出的致命错误（throw），而不是普通的 panic。这是 Go 语言设计上的有意为之，旨在防止更严重的数据损坏问题。

作为 Go 开发者，我们应该理解这一设计背后的哲学，并采取适当的预防措施，而不是试图"修复"这种设计。合理使用同步原语，避免 map 的并发访问，才是解决问题的根本之道。