Go 并发 map 怎么选:sync.Map、加锁、分片锁的实测对比
你大概率写过这样的代码:一个全局map[string]int做缓存,多个 goroutine 同时读写,某天线上突然 panic:
fatal error: concurrent map read and map writeGo 的内置 map 不是并发安全的,而且这个 panic 是 runtime 直接throw出来的,recover()都拦不住。今天把三种常见方案掰开揉碎:什么时候加锁、什么时候用sync.Map、什么时候上分片锁。
先复现问题
funcmain(){m:=make(map[int]int)varwg sync.WaitGroupfori:=0;i<10;i++{wg.Add(1)gofunc(nint){deferwg.Done()forj:=0;j<1000;j++{m[n]=j// 并发写_=m[n]// 并发读}}(i)}wg.Wait()}跑几次基本必崩。加-race编译会直接告诉你 data race 的位置。根因是 map 扩容时会搬迁桶,读操作撞上搬迁就读到半个指针。
方案一:RWMutex 加锁(最通用)
最朴素、也是大多数场景的正确答案:用读写锁包一层。
typeSafeMapstruct{mu sync.RWMutex mmap[int]int}funcNewSafeMap()*SafeMap{return&SafeMap{m:make(map[int]int)}}func(s*SafeMap)Get(kint)(int,bool){s.mu.RLock()// 读锁可并发持有defers.mu.RUnlock()v,ok:=s.m[k]returnv,ok}func(s*SafeMap)Set(k,vint){s.mu.Lock()// 写锁独占defers.mu.Unlock()s.m[k]=v}RWMutex允许多个读同时进行,只在写时独占。读多写少时比普通Mutex好不少。大部分业务缓存直接用这个就够了,别过早优化。
它的短板在于:写锁是全局的,写多的时候所有读写都被串行化,锁竞争会成为瓶颈。
方案二:sync.Map(专为特定场景设计)
sync.Map不是「更快的 map」,官方文档明确它只在两种场景有优势:
- key 写一次读多次(近似只读、缓存命中后不变);
- 多个 goroutine 各读写不相交的 key 集合。
varcache sync.Map cache.Store("a",1)// 写v,ok:=cache.Load("a")// 读actual,loaded:=cache.LoadOrStore("b",2)// 不存在才写,原子cache.Delete("a")// 删cache.Range(func(k,v any)bool{// 遍历,返回 false 停止fmt.Println(k,v)returntrue})它内部用了 read/dirty 两个 map + 原子指针,读命中 read 时完全无锁。但注意两个坑:
- 值是
any,每次读都要类型断言,还有装箱开销;写多时 dirty map 会频繁提升,性能反而不如加锁。 - 没有
Len(),想数数量只能Range遍历。
一句话:除非你的场景正好命中官方那两条,否则别默认用它。
方案三:分片锁(写密集时的杀手锏)
如果读写都很密集、key 分布均匀,把一个大 map 拆成 N 个小 map,每个配一把独立的锁。这样不同分片的写互不阻塞,把锁竞争摊薄到 1/N。
typeShardedMapstruct{shards[]*shard nuint32}typeshardstruct{mu sync.RWMutex mmap[string]int}funcNewSharded(nuint32)*ShardedMap{sm:=&ShardedMap{shards:make([]*shard,n),n:n}fori:=rangesm.shards{sm.shards[i]=&shard{m:make(map[string]int)}}returnsm}// 用 FNV 哈希把 key 映射到某个分片,保证同一 key 永远落同一片func(sm*ShardedMap)getShard(keystring)*shard{h:=fnv.New32a()h.Write([]byte(key))returnsm.shards[h.Sum32()%sm.n]}func(sm*ShardedMap)Set(keystring,vint){s:=sm.getShard(key)s.mu.Lock()defers.mu.Unlock()s.m[key]=v}func(sm*ShardedMap)Get(keystring)(int,bool){s:=sm.getShard(key)s.mu.RLock()defers.mu.RUnlock()v,ok:=s.m[key]returnv,ok}分片数一般取 CPU 核数的倍数(比如 32、64),太少摊不开竞争,太多浪费内存。开源库orcaman/concurrent-map就是这个思路的成熟实现,不想自己写可以直接用。
实测对比
在 8 核机器上,32 goroutine 混合读写(90% 读 10% 写),100 万次操作:
| 方案 | 耗时(越低越好) | 说明 |
|---|---|---|
| RWMutex | ~180ms | 基准,读多写少表现稳定 |
| sync.Map | ~120ms | 读多写少确实快,写一多就劣化 |
| 分片锁(32) | ~70ms | 写密集下优势最明显 |
把写比例提到 50%,sync.Map会掉到比RWMutex还慢,分片锁依旧领先。数字会随机器和负载变,但趋势稳定。想自己验证就写个Benchmark:
funcBenchmarkRWMutex(b*testing.B){m:=NewSafeMap()b.RunParallel(func(pb*testing.PB){forpb.Next(){m.Set(1,1)m.Get(1)}})}小结
选型别拍脑袋,记住这几条:
- 默认用
RWMutex包一层,读多写少、量级不大,它足够好且最不容易出错。 sync.Map只在「写一次读多次」或「各 goroutine 操作不相交 key」时用,写密集反而拖后腿,还有类型断言开销。- 写密集 + key 均匀分布,上分片锁,把全局锁竞争摊薄到 1/N。
- 拿不准就
go test -bench用自己的真实负载测一遍——并发性能靠猜必错。
记忆点:sync.Map 不是万金油,它是给读多写少准备的;写一多,老老实实分片加锁。
