Go 并发读写 map 怎么选：map+RWMutex、sync.Map、分片 map 对比

Go 里普通 map 不是并发安全容器。只要有多个 goroutine 同时读写同一个 map，就应该主动设计同步策略。问题是：到底用 map + sync.RWMutex、直接用 sync.Map，还是自己做分片 map？这篇按问答方式给一个实用结论：默认先选 map + RWMutex；读多写少、键分布比较均匀时考虑 sync.Map；写入很热、单锁竞争明显时再上分片。

Go 官方 sync.Map 文档也提醒：sync.Map 是专门化类型，多数代码仍应使用普通 Go map 搭配单独的锁或协调机制。理解这个边界，比记住某个固定答案更重要。

使用场景：问题到底出在哪

很多 Go 问答里会出现类似问题：我有一个全局缓存、连接状态表、配置快照或统计计数表，多个 goroutine 都要访问它，应该用哪种 map？先把场景拆清楚：

• 读多写少：初始化或偶尔刷新，绝大多数请求只是读取。
• 读写均衡：业务请求既读又改，更新频率不低。
• 热点写入：少数 key 被频繁更新，例如某个租户、某个任务 ID、某个计数项。
• 维护优先：团队更需要清晰类型、简单调试和可控生命周期。

方案选择不是看名字高级不高级，而是看锁竞争、键分布、类型安全和后续维护成本。

候选方案：map+RWMutex、sync.Map、分片 map

方案一：map + sync.RWMutex

这是最常见、最容易审查的方案。读操作用 RLock，写操作用 Lock，数据结构保持强类型：

type UserCache struct {
    mu   sync.RWMutex
    data map[int64]User
}

func (c *UserCache) Get(id int64) (User, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    user, ok := c.data[id]
    return user, ok
}

func (c *UserCache) Set(id int64, user User) {
    c.mu.Lock()
    defer c.mu.Unlock()
    c.data[id] = user
}

它的优点是类型清楚、生命周期可控、删除和遍历都符合普通 map 直觉。缺点是所有 key 共用一把锁，写入频繁时容易成为竞争点。

方案二：sync.Map

sync.Map 内置并发访问能力，适合两类典型场景：某个 key 写入一次后被多次读取；或者多个 goroutine 操作的 key 集合相对独立。它的 API 是 Load、Store、LoadOrStore、Delete 等：

var cache sync.Map

func Save(id int64, user User) {
    cache.Store(id, user)
}

func Find(id int64) (User, bool) {
    value, ok := cache.Load(id)
    if !ok {
        return User{}, false
    }
    user, ok := value.(User)
    return user, ok
}

它的问题也明显：value 需要类型断言，复杂更新逻辑不如普通 map 直观；如果你需要频繁遍历、批量替换、维护多个字段的一致性，代码反而会绕。

方案三：分片 map

分片 map 是把一张大 map 拆成多个小 map，每个分片有自己的锁。访问时先根据 key 计算分片下标，再锁定对应分片：

const shardCount = 32

type shard struct {
    mu   sync.RWMutex
    data map[string]int64
}

type CounterMap struct {
    shards [shardCount]shard
}

func (m *CounterMap) pick(key string) *shard {
    h := fnv32(key)
    return &m.shards[h%shardCount]
}

分片适合高并发写入或 key 空间很大的场景。它的代价是实现复杂度上升：分片数量怎么选、遍历怎么做、扩容怎么处理、指标怎么观察，都要自己承担。

对比维度：读写比例、热点键和维护成本

选择时可以先问三个问题。

• 读写比例：读远多于写吗？如果是，RWMutex 或 sync.Map 都可能合适；如果写也很多，要看锁竞争。
• 键空间：请求是否集中在少数热点 key？热点明显时，单锁和 sync.Map 都可能被写入路径拖慢。
• 维护成本：团队是否能接受类型断言和自定义分片逻辑？如果不能，先用普通 map 加锁。

推荐选择：先简单，再按压力升级

我的推荐顺序是：

1. 业务刚开始：先用 map + RWMutex，因为它最清楚，也最容易加日志和测试。
2. 读多写少且 key 分布均匀：尝试 sync.Map，尤其适合缓存对象、只增不常改的元数据。
3. 写入竞争明显：先用压测或指标确认单锁等待，再考虑分片 map。
4. 需要多字段一致性：不要只看 map 容器，可能应该把状态收敛到一个拥有者 goroutine、数据库事务或更清晰的状态机里。

不适用情况：别把 sync.Map 当万能容器

sync.Map 不是“更高级的 map”。下面几种情况要谨慎：

• 你需要强类型 API，并希望编译期尽量发现错误。
• 你经常要遍历全量数据并做一致性判断。
• 每次更新都依赖旧值和多个字段的组合状态。
• key 很少但写入极热，此时分片也未必能解决热点，需要重新设计写入路径。

另外，Go 的 内存模型强调同步操作之间的可见性关系。不要用“我测试没问题”代替同步设计；并发读写共享数据时，必须有明确的同步边界。

决策表：一眼选方案

总结

Go 并发 map 的选择可以记成一句话：默认 map + RWMutex，读多写少看 sync.Map，高写入竞争再考虑分片。真正做决定前，先用业务读写比例和 key 分布说话，再用压测或运行指标确认瓶颈。这样选出来的方案通常不会最花哨，但会更稳、更容易长期维护。