Go 并发读写 map 的保护结构

我在把一个单线程缓存改成多 goroutine 访问时，最先遇到的不是“锁怎么加”，而是保护结构选错：读写都用一把 sync.Mutex 最稳；读明显多于写且临界区很短时，再评估 sync.RWMutex；只有键只写一次后反复读取，或不同 goroutine 操作相互独立的键集合时，sync.Map 才值得考虑。普通 Go map 只要存在并发写入，就必须通过同步机制保护。

本文只讨论互斥锁、读写锁与 sync.Map 的选择，不把示例压测当成线上结论。官方资料入口：https://go.dev/blog/maps、https://pkg.go.dev/sync。

先确定共享状态边界

先问三个问题：是否有 goroutine 写入？读写是否需要同时维护计数、过期时间等复合不变量？键和值的类型是否应该在编译期约束？只读 map 可以被多个 goroutine 读取，但一旦出现赋值、删除或与读取并发，就不能靠“通常没问题”来保护。

这一步也决定指标：至少记录吞吐、读写延迟、锁等待时间和内存占用。只看平均耗时，容易把偶发写入造成的长尾藏起来。

默认方案：普通 map 配一把 Mutex

如果业务需要“读取并修改再写回”，或者读写比例还没有可靠数据，普通 map 加 sync.Mutex 往往是最容易维护的起点。把 map 和锁放进同一个类型，避免调用方绕过保护入口。

package main

import "sync"

type CounterMap struct {
	mu sync.Mutex
	// map 与锁属于同一个共享状态边界
	values map[string]int
}

func (c *CounterMap) Add(key string, delta int) {
	c.mu.Lock()
	defer c.mu.Unlock() // 无论函数如何返回，都释放独占锁
	c.values[key] += delta
}

func (c *CounterMap) Get(key string) (int, bool) {
	c.mu.Lock()
	defer c.mu.Unlock() // 读也走同一把锁，避免与写并发
	value, ok := c.values[key]
	return value, ok
}

构造时初始化 values，方法只在锁内读写。这个版本的代价是读也会排队，但它能完整保护“取旧值、计算、写回”这一组动作，先用 go test -race 证明无竞态，再谈优化更可靠。

读多写少：再评估 RWMutex

sync.RWMutex 允许多个读者同时进入，但写入仍然需要独占。它适合读操作短、写操作相对少且读锁竞争确实成为瓶颈的场景，并不等于“读越多就一定越快”。锁升级、长时间持有读锁和读写比例抖动，都会让收益消失。

type Snapshot struct {
	mu     sync.RWMutex
	// 只有访问方法持有锁时才读取这个 map
	values map[string]string
}

func (s *Snapshot) Lookup(key string) (string, bool) {
	s.mu.RLock()
	defer s.mu.RUnlock() // 读路径只保留必要的查找时间
	value, ok := s.values[key]
	return value, ok
}

func (s *Snapshot) Replace(key, value string) {
	s.mu.Lock()
	defer s.mu.Unlock() // 写入需要排斥所有读者
	s.values[key] = value
}

压测时固定键数量、命中率、goroutine 数量和读写比例，再比较 ops/s、p95 延迟与锁等待。比如分别跑 99:1、9:1、1:1 三组比例；如果 RWMutex 只在一组人工构造的读密集场景获益，就不要把它升级成默认封装。

sync.Map 只解决特定访问模型

sync.Map 的确支持并发使用，但它不是带泛型的普通 map 替代品。官方文档把它重点放在两类场景：某个键只写入一次后被反复读取；或者多个 goroutine 读写彼此独立的键。它的值是 any，类型断言和业务不变量仍由调用方负责。

如果业务动作是“先检查余额，再更新余额”，或要同时更新 map 与另一个字段，单独调用 Load、Store 并不能自动把整个业务动作变成原子操作。此时普通 map 加锁通常更清楚，LoadOrStore 也只适合它明确覆盖的单键动作。

用指标和工具复查选择

建议把同一套 workload 分成三轮：先用 -race 找未同步访问，再用基准测试比较吞吐与 p95，最后观察锁等待和分配。基准命令可以这样组织：

# 先跑竞态检测，确认比较的是正确程序
go test -race ./...
# 固定基准时间，减少不同实现之间的测量偏差
go test -bench=BenchmarkMap -benchmem -benchtime=5s ./...

最后的选择顺序可以固定成：先保证所有访问都被保护，再确认业务不变量，再用同一 workload 测量。没有基线数据时，优先可读的普通 map 加 Mutex；有证据表明读锁竞争明显时才换 RWMutex；符合专用模型且能接受 any 时再用 sync.Map。

多个 goroutine 只读 map，需要加锁吗？

没有任何并发写入时，多个 goroutine 读取 map 通常不需要额外同步；但只要生命周期中可能出现写入，就应把初始化、替换和读取的边界一起设计清楚。

RWMutex 一定比 Mutex 快吗？

不一定。读锁本身也有协调成本，临界区很短或写入不少时，Mutex 可能更稳定，最终要用固定 workload 的吞吐和长尾指标决定。

sync.Map 能替代所有并发 map 吗？

不能。它适合特定键访问模型；涉及强类型、复合不变量或复杂生命周期时，普通 map 配锁通常更直观。