Go 并发 map 怎么选:sync.Map、加锁、分片锁的实测对比

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;i10;i{wg.Add(1)gofunc(nint){deferwg.Done()forj:0;j1000;j{m[n]j// 并发写_m[n]// 并发读}}(i)}wg.Wait()}跑几次基本必崩。加-race编译会直接告诉你 data race 的位置。根因是 map 扩容时会搬迁桶,读操作撞上搬迁就读到半个指针。方案一:RWMutex 加锁(最通用)最朴素、也是大多数场景的正确答案:用读写锁包一层。typeSafeMapstruct{mu sync.RWMutex mmap[int]int}funcNewSafeMap()*SafeMap{returnSafeMap{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 不是万金油,它是给读多写少准备的;写一多,老老实实分片加锁。