Go 普通 map 并发读写为什么会报错？互斥锁和 sync.Map 怎么选

Go 里普通 map 很常用，但一旦多个 goroutine 同时读写它，程序可能直接报错。很多初学者会疑惑：我只是读取和更新几个 key，为什么不能自动保证安全？到底该加锁，还是直接换成 sync.Map？

这篇文章按 FAQ 方式回答：普通 map 并发读写为什么会出问题、哪些理解是误区、怎么用互斥锁保护、什么时候才适合 sync.Map，以及上线前怎么做最小检查。

问题原文：普通 map 并发读写为什么会报错

看一个最小例子。一个 goroutine 不断写入 map，另一个 goroutine 同时读取：

package main

import (
    "fmt"
    "time"
)

func main() {
    scores := map[string]int{"go": 1}

    go func() {
        for i := 0; i 

这类代码在压力下可能出现 fatal error: concurrent map read and map write。它不是业务异常，而是运行时发现普通 map 被多个 goroutine 不安全地同时访问。

先给结论：map 不是并发容器

Go 普通 map 的设计重点是高效存取，不是自动处理多 goroutine 的读写协调。只要存在“至少一个 goroutine 写入，同时另一个 goroutine 读或写”的情况，就需要额外保护。

可以先记住这个规则：

• 多个 goroutine 只读同一个已经不再变化的 map，通常没有问题。
• 只要有 goroutine 会写入，就要加锁、改用并发安全结构，或者把访问收敛到单个 goroutine。
• sync.Map 不是普通 map 的无脑替代品，它适合特定读写模式。

常见误区：只读就一定安全吗

“只读安全”有一个前提：这个 map 已经构造完成，后续没有任何 goroutine 会修改它。如果后台任务会刷新配置、更新缓存、删除过期 key，那么读操作就不是处在纯只读场景里。

另一个误区是“偶尔写一下没关系”。并发问题不按概率承诺稳定。低并发时可能不出现，压测或线上流量波动时才暴露。只要结构上存在并发读写，就应该按不安全处理。

正确做法一：用互斥锁保护普通 map

如果业务需要普通 map 的完整能力，比如频繁更新、删除、遍历、按业务逻辑组合多个操作，最直接的方式是用 sync.RWMutex 把访问包起来。

package main

import "sync"

type ScoreStore struct {
    mu     sync.RWMutex
    scores map[string]int
}

func NewScoreStore() *ScoreStore {
    return &ScoreStore{
        scores: make(map[string]int),
    }
}

func (s *ScoreStore) Set(name string, score int) {
    s.mu.Lock()
    defer s.mu.Unlock()
    s.scores[name] = score
}

func (s *ScoreStore) Get(name string) (int, bool) {
    s.mu.RLock()
    defer s.mu.RUnlock()
    score, ok := s.scores[name]
    return score, ok
}

这里的重点不是“加一把锁”这么简单，而是把 map 隐藏在结构体内部。外部只能通过 Set、Get 访问，避免某个调用方绕过锁直接操作底层数据。

正确做法二：读多写少时考虑 sync.Map

sync.Map 适合一些读多写少、key 生命周期相对独立的场景。例如缓存已经生成的只读结果、按 key 存储一次后多次读取、多个 goroutine 读写不同 key。它提供 Load、Store、Delete、LoadOrStore 等方法。

package main

import "sync"

var cache sync.Map

func SaveScore(name string, score int) {
    cache.Store(name, score)
}

func ReadScore(name string) (int, bool) {
    value, ok := cache.Load(name)
    if !ok {
        return 0, false
    }
    score, ok := value.(int)
    return score, ok
}

注意 sync.Map 的值是 any，读取后通常需要类型断言。它也不适合所有组合操作。如果一次业务动作需要同时检查多个 key、更新多个字段，普通 map 加锁往往更清晰。

边界情况：别把所有 map 都换成 sync.Map

看到并发问题后，很多人会把项目里的 map 全部替换成 sync.Map。这通常不是好选择。原因有三点：

• 类型约束变弱，读取后需要断言，代码可读性下降。
• 复杂业务操作仍然需要额外协调，不能只靠单次 Load 或 Store。
• 普通 map 加锁在很多写多或组合操作场景里更直观。

选择时可以按这个顺序判断：如果只是局部共享状态，先封装普通 map 并加锁；如果是读多写少、key 相互独立、操作粒度简单，再考虑 sync.Map；如果状态变更有严格顺序，也可以让单个 goroutine 通过 channel 管理状态。

延伸问题：上线前怎么确认没有数据竞争

上线前至少做两件事。第一，把共享 map 收敛到结构体内部，不让调用方直接拿到底层引用。第二，在测试或本地压测时打开 race 检查：

go test -race ./...

如果是一个小 demo，也可以直接运行：

go run -race main.go

race 检查不是性能压测工具，它的目标是发现多个 goroutine 对同一内存位置的非协调访问。它不能替你证明业务一定快，但能尽早暴露很多并发访问问题。

总结

Go 普通 map 不是并发容器。只要存在并发写入，就要用互斥锁、sync.Map 或单 goroutine 管理访问。普通 map 加锁适合大多数业务状态，sync.Map 更适合读多写少且 key 独立的缓存类场景。真正可靠的做法是封装访问入口，再用 race 检查和压测验证。