Go map 为什么并发读写会崩溃

Go 普通 map 并不支持并发读写。一个 goroutine 正在执行赋值、删除或扩容时，另一个 goroutine 同时读取、遍历甚至继续写入，程序就进入了未同步访问；常见表现是 fatal error: concurrent map read and map write，也可能先出现数据竞争报告或其他不可依赖的结果。

官方资料：https://go.dev/doc/articles/race_detector

关键不是“把某一次崩溃重试过去”，而是为共享 map 选定唯一的同步边界：用锁覆盖完整操作，或让一个 goroutine 独占 map，再通过消息传递访问它。

普通 map 为什么不能自动处理并发

map 是语言内置的数据结构，读操作也可能观察到内部桶、计数和扩容状态。写入不仅是给某个键换值，还可能插入新键、删除元素或触发内部结构调整。Go 官方文档明确指出，map 不能安全地被并发使用；读写访问必须由同步机制协调。

这里要区分两个概念：只有多个 goroutine 同时读取且没有任何写入时，普通 map 通常可以被安全读取；一旦存在写入，就必须把所有相关访问纳入同一个同步设计。len(m)、delete(m, k)、range m 和 m[k]++ 也不能脱离这个边界。

先把共享 map 的访问边界找全

排查时不要只搜索报错字符串。先定位 map 的创建位置，再列出所有传递它的函数、结构体方法和 goroutine。尤其要关注“读取函数加锁、更新函数没加锁”“遍历时另一个请求删除”“先判断再更新”这类跨函数边界。

type Cache struct {
    mu    sync.RWMutex
    items map[string]string
}

func (c *Cache) Get(key string) (string, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()

    // 读锁覆盖查找和取值，避免写入同时改变 map 的内部状态。
    value, ok := c.items[key]
    return value, ok
}

func (c *Cache) Put(key, value string) {
    c.mu.Lock()
    defer c.mu.Unlock()

    // 写锁覆盖赋值，后续若发生扩容也不会与读操作交叉。
    c.items[key] = value
}

这个例子还需要在构造函数中初始化 items。锁保护的是同一个 map 实例，不能在某个方法里复制结构体后再对副本加锁；如果缓存还要提供遍历或批量更新，也要为这些方法定义清楚锁覆盖的完整范围。

用 mutex 或 RWMutex 保护复合操作

如果业务需要“读取旧值、计算新值、写回”作为一个整体，不能只给最后一行赋值加锁。锁必须覆盖整个复合操作，否则两个 goroutine 仍可能同时读到旧值并互相覆盖结果。

func (c *Cache) Increment(key string) int {
    c.mu.Lock()
    defer c.mu.Unlock()

    // 读改写必须在同一把写锁内完成，避免丢失更新。
    current := c.counts[key]
    current++
    c.counts[key] = current
    return current
}

读多写少、且读操作可以接受短暂阻塞时，可以使用 sync.RWMutex；读写比例不明确时，普通 sync.Mutex 往往更容易保持正确。遍历期间不要把 map 的内部引用交给锁外代码，否则方法返回后调用者仍可能无锁访问共享数据。

什么时候换成单协程所有权或 sync.Map

另一种方案是让一个 goroutine 独占普通 map，其他 goroutine 通过 channel 发送查询和更新请求。这样 map 本身没有跨 goroutine 直接访问，但要考虑请求排队、退出和错误返回。

sync.Map 适合特定访问模式，例如键只写入一次后被频繁读取，或多个 goroutine 操作互不重叠的键集合。它不是普通 map 的无条件替代品，也不能自动把“先 Load、再根据结果决定 Store”变成一个业务原子操作；需要这类语义时，应使用其提供的组合方法，或回到互斥锁。

用 -race 找到遗漏访问

竞态检测器适合帮助定位访问路径，但它不能替代同步设计。把覆盖共享 map 的测试用例用 race 模式运行，重点查看报告中的读写双方和调用栈；如果测试没有触发某条路径，仍需要人工检查生命周期和后台 goroutine。

# 在测试阶段让竞态检测器报告未同步的共享访问。
go test -race ./...

# 运行一个会创建并发访问的命令行程序。
go run -race ./cmd/cache

最后可以用下面的顺序缩小范围：确认 map 是否被多个 goroutine 持有；列出写入、删除、遍历和复合更新；确定唯一同步边界；再用 -race 检查遗漏。不要把运行时偶尔没有崩溃当成修复完成。

相关问题

并发读 map 也一定会崩溃吗？

多个 goroutine 只读同一个 map，且 map 在这段时间没有任何写入时，通常可以安全读取；真正需要避免的是读写或写写没有同步关系。

加了 RWMutex 还是报错，常见原因是什么？

通常是仍有一条访问路径绕过了锁，或者把带锁结构体复制后使用了副本。把遍历、删除、len 和后台任务也纳入访问清单。

sync.Map 会让所有并发逻辑都安全么？

它只保证自身方法的并发语义，不会自动保护存入值内部的字段，也不会替业务完成多步条件更新。遇到复合事务式操作，应使用明确的锁或单协程所有权。

参考资料

Go 数据竞争检测器：https://go.dev/doc/articles/race_detector

Go 内存模型：https://go.dev/ref/mem

Go 官方 map 说明：https://go.dev/blog/maps

sync.Map 文档：https://pkg.go.dev/sync#Map