Go 并发读写 map 为什么偶发 fatal error

如果日志里出现 fatal error: concurrent map read and map write，根因通常不是 map “偶发坏掉”，而是普通 map 被多个 goroutine 同时访问，至少有一个访问会修改它。解决办法是让所有读、写、删、遍历都经过同一个同步边界；只有在数据模型适合时，才考虑 sync.Map。

先复现：读写 map 共用同一个无保护容器

做一个最小计数器就能看出问题：一个 goroutine 不断累加键值，另一个 goroutine 同时读取。普通 map 的元素读写和内部结构调整可能交叉，运行时会主动终止进程，因此它不是可以靠 recover 稳定兜住的普通业务 panic。

package main

import "sync"

func main() {
	counts := make(map[string]int)
	var wg sync.WaitGroup

	// 写入 goroutine 和读取 goroutine 共享同一个普通 map。
	wg.Add(2)
	go func() {
		defer wg.Done()
		for i := 0; i 

这里的关键不是循环次数，而是共享状态没有明确的所有权。即使低并发时“多数时候没事”，也不能把偶然没触发当作安全证明。

把访问边界放进结构里

对于类型明确的业务数据，我更建议保留 map[string]int，在封装层统一使用 sync.RWMutex。读方法用 RLock，修改和删除用 Lock；不要让调用方拿到内部 map 后绕过封装。

type Counter struct {
	mu sync.RWMutex
	m  map[string]int
}

func NewCounter() *Counter {
	return &Counter{m: make(map[string]int)} // 初始化后再提供并发方法。
}

func (c *Counter) Add(key string) {
	c.mu.Lock()
	defer c.mu.Unlock() // 覆盖整个读改写过程，避免丢失更新。
	c.m[key]++
}

func (c *Counter) Get(key string) (int, bool) {
	c.mu.RLock()
	defer c.mu.RUnlock() // 读取也必须进入同一个同步边界。
	v, ok := c.m[key]
	return v, ok
}

func (c *Counter) Delete(key string) {
	c.mu.Lock()
	defer c.mu.Unlock() // delete 会修改 map 的内部状态。
	delete(c.m, key)
}

锁保护的是“访问路径”，不是某一行代码。若返回值是指向可变结构的指针，解锁后继续修改该结构仍可能产生新的竞态；这时要复制值，或把值的修改也封装进锁内。

用 race 检查锁是否真的覆盖了共享数据

修完后先跑竞态检测，而不是只观察程序是否“没再退出”。把并发场景写成测试，命令如下：

# 竞态检测会给出冲突访问的调用栈。
go test -race ./...

检查清单有三项：所有读写是否经过同一把锁；遍历期间是否保持读锁或先复制快照；map 的 value 如果是 slice、指针或嵌套 map，解锁后是否仍被多个 goroutine 修改。第三项经常被忽略：外层 map 安全，不等于内部对象自动安全。

什么时候换成 sync.Map

sync.Map 的确支持多个 goroutine 并发使用，但它不是普通 map 的无脑升级版。它牺牲了静态类型便利，取值后通常还要做类型断言；Range 也不代表一次一致性快照。

如果缓存键通常只写一次、之后反复读取，或者不同 goroutine 主要操作互不相同的键，可以做基准测试后评估它。若业务需要同时维护计数、过期时间、容量等不变量，类型明确的 map 加锁往往更直观。

常见问题

只给写操作加锁，读操作需要锁吗？

需要。读与写同时发生仍是不安全访问，读取、删除和遍历都应进入同一个同步策略。

出现 fatal error 后用 recover 能恢复吗？

不能把它当作普通 panic 设计恢复流程。应修复共享访问关系，并用 -race 找剩余竞态。

RWMutex 一定比 Mutex 快吗？

不一定。读多写少且临界区合适时才可能受益；锁竞争、临界区大小和调度开销仍要用基准测试判断。

判断这类问题可以记成一句话：先找出谁拥有 map，再让所有访问都经过同一个边界；只有读写模式明确匹配时，才把替代结构纳入测试。