Go语言并发下map为什么不安全_Golang并发数据结构解析-Golang

Go 的 map 并发读写会 panic，因其非并发安全；sync.Map 适用于读多写少场景，但有 len 不支持、迭代受限等限制；手动加锁更可控。

为什么并发读写 map 会 panic

Go 的内置 map 不是并发安全的，一旦有 goroutine 在写（比如调用 map[key] = value 或 delete()），同时另一个 goroutine 在读（比如 v := map[key]），运行时大概率触发 fatal error: concurrent map read and map write。这不是概率问题，而是设计使然：底层哈希表在扩容、搬迁桶、调整结构时会修改指针和字段，没有加锁保护，多线程访问必然导致内存状态不一致。

sync.Map 适合什么场景

sync.Map 是标准库提供的并发安全替代方案，但它不是万能的“高性能 map 替代品”，而是一个为**读多写少**场景优化的数据结构：

• 读操作（Load）几乎无锁，使用原子操作 + 副本机制，性能接近原生 map
• 写操作（Store）会先尝试写入只读区（read），失败再加锁写入 dirty；首次写入后，后续对同一 key 的读会从 dirty 搬到 read，但不会自动同步全部 dirty 到 read
• 不支持 len()，因为长度需遍历两个 map，无法原子获取；也不支持 range 迭代（只能用 Range() 回调）
• 值类型必须是可比较的（满足 ==），且不能是函数、map、slice 等不可比较类型

手动加锁比 sync.Map 更可控

如果业务逻辑明确、读写比例均衡，或需要 len()、迭代、自定义删除逻辑等，直接用 sync.RWMutex 包裹普通 map 往往更简单、更易测试：

var m = struct {
    sync.RWMutex
    data map[string]int
}{data: make(map[string]int)}

// 读
m.RLock()
v := m.data["key"]
m.RUnlock()

// 写
m.Lock()
m.data["key"] = 42
m.Unlock()

注意：RWMutex 的写锁会阻塞所有读，而 sync.Map 的写可能引发脏数据延迟可见；若存在大量写竞争，RWMutex 可能比 sync.Map 更快——因为后者内部仍要处理 read/dirty 切换开销。