个人主页 我不会起名字322 欢迎各位大佬莅临其他栏目 技术栈学习笔记 其他栏目 力扣Hot100题目解析 其他栏目 Go项目学习笔记 其他栏目 redis 其他栏目 mysql 文章目录Go map 为什么不能并发读写fatal error 背后的扩容与渐进搬迁先说结论我遇到的事反直觉一不崩不代表安全为什么 Go 选择直接崩而不是内部加锁底层长什么样hmap 与 bucket什么时候会扩容反直觉二扩容是慢慢搬的不是一次性搬完还有个坑删掉的 key 不释放内存三种并发方案怎么选方案一sync.RWMutex 原生 map通用首选方案二sync.Map别滥用方案三分片加锁高并发写选型速查排查速查表小结Go map 为什么不能并发读写fatal error 背后的扩容与渐进搬迁摘要从一次 fatal error: concurrent map read and map write 说起。讲清 Go 为什么选择直接崩而不是加锁、map 底层的 hmap 与 bucket 结构、装载因子 6.5 触发的翻倍扩容与 overflow 过多触发的等量扩容以及最关键的渐进式搬迁机制——为什么搬迁期间并发读写最危险。最后对比 sync.RWMutex map、sync.Map、分片加锁三种方案的适用边界并说明为什么 fatal error 无法用 recover 兜底。标签go · golang · map · 并发 · sync.Map专栏Go 学习笔记先说结论Go 的 map不是并发安全的并发读写会触发fatal error而这个错误无法用recover兜底进程直接退出。更危险的是并发读写不一定每次都崩。没崩不代表安全你可能在读脏数据。底层原因不是忘了加锁这么简单而是 map 存在渐进式扩容搬迁——搬迁期间同一份数据分散在两块数组里任何并发写都会破坏搬迁进度。三种方案sync.RWMutex map通用首选、sync.Map只适合读多写少且 key 稳定、分片加锁高并发写。我遇到的事需求很简单起 10 个 goroutine 并发往一个 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*1000j]j}}(i)}wg.Wait()}跑起来程序挂了fatal error: concurrent map writes goroutine 18 [running]: runtime.throw({0x4c1a2e?, 0x0?}) .../runtime/panic.go:992 0x71 runtime.mapassign_fast64(...) .../runtime/map_fast64.go:120 0x3d8 main.main.func1(...)我当时的第一反应是加个recover兜一下。然后发现根本兜不住——fatal error和panic是两回事recover只能捕获panic。这个进程是硬退出的没有任何挽救余地。第二反应是那我小心点别同时写就行。然后我把并发数调小、加了点 sleep程序居然跑通了。于是我以为问题解决了。这个以为才是最危险的。反直觉一不崩不代表安全Go 对 map 并发的检测依赖hmap里的一个标志位hashWriting写操作开始时置位结束时清除。如果读操作mapaccess发现这个标志被置了就抛出fatal error。但这个检测不是每次都能命中——它依赖时序取决于两个操作是否真的重叠在那一瞬间。所以并发读写可能崩也可能不崩不崩的时候你可能正读到一个写了一半的值或者读到一个正在搬迁中的桶里的数据这种偶尔读到脏数据的问题不会让程序挂掉只会让业务逻辑在半夜出错比直接崩溃难查十倍。结论不要用没崩来判断 map 并发是否安全。要判断就用go test -racerace detector 是基于 happens-before 的静态分析能抓到那些这次没崩的隐患。为什么 Go 选择直接崩而不是内部加锁这是设计上的取舍不是疏忽。map 的底层实现涉及哈希计算、桶定位、overflow 链表、扩容搬迁。如果内部加一把全局锁所有单 goroutine 场景绝大多数情况都要为用不上的锁付出代价读操作也要加锁性能直接砍一大截加锁粒度选不好高并发下就是瓶颈。Go 团队的选择是把这个决定权交给开发者。你需要并发就用sync包自己控制不需要就不付代价。想明白了这一点后面选型就不纠结了。底层长什么样hmap 与 bucketmap 的运行时结构是hmaptypehmapstruct{countint// 元素个数len(m) 直接读它flagsuint8// 状态标志hashWriting 就在这Buint8// 桶数量的对数桶数 2^Bnoverflowuint16// overflow 桶的近似数量hash0uint32// 哈希种子防止哈希碰撞攻击buckets unsafe.Pointer// 当前桶数组oldbuckets unsafe.Pointer// 扩容时的旧桶数组nevacuateuintptr// 搬迁进度下一个待搬迁的桶编号extra*mapextra// overflow 桶相关}每个桶bmap固定装8 个 key-value 对装满了就用overflow指针链一个新桶buckets ├─ bmap[0] 8个槽 → overflow → bmap → nil ├─ bmap[1] 8个槽 ├─ bmap[2] 8个槽 └─ ... 共 2^B 个注意oldbuckets和nevacuate这两个字段——它们是理解并发危险的关键。什么时候会扩容两种触发条件1. 装载因子超过 6.5 → 翻倍扩容装载因子 count / (2^B * 8)。当平均每个桶装的元素超过 6.5 个说明桶快满了碰撞概率上升。此时新建2^(B1)个桶即容量翻倍。2. overflow 桶太多 → 等量扩容有时候元素不多但反复增删导致 overflow 链表很长、数据很稀疏。这时桶数不变重新排布一次让数据更紧凑。判断逻辑在runtime/map.go里if!h.growing()(overLoadFactor(h.count1,h.B)||tooManyOverflowBuckets(h.noverflow,h.B)){hashGrow(t,h)}反直觉二扩容是慢慢搬的不是一次性搬完这是整篇文章最值得记住的一点。如果 map 里有几百万个元素一次性搬迁会造成明显的卡顿。Go 的做法是渐进式搬迁hashGrow只分配新桶数组把旧桶挂到oldbuckets设置nevacuate 0不搬任何数据之后每次对 map 的写操作mapassign或删除mapdelete顺手搬迁 1~2 个桶搬迁完成前oldbuckets和buckets同时存在读操作需要判断目标 key 在旧桶还是新桶全部搬完oldbuckets置 nil扩容结束。可以通过h.growing()判断是否在搬迁中本质上就是看oldbuckets ! nil。这解释了为什么并发写如此致命搬迁期间同一个 map 的数据分散在两个数组里由一个nevacuate计数器维护进度。此时如果另一个 goroutine 也在写它可能把一个 key 写进新桶而搬迁逻辑正准备从旧桶搬同一个 key修改了搬迁进度相关的状态读到一个两边都没有的中间态。结果就是数据丢失、读到脏值或者运行时检测到不一致直接throw。这不是小概率的时序巧合而是结构上的必然。也正因为搬迁是渐进的一次并发写的影响可能在几千次操作之后才暴露——这就是这类 bug 最难复现的原因。还有个坑删掉的 key 不释放内存m:make(map[int]int,1000000)// 填入 100 万个元素fork:rangem{delete(m,k)}// len(m) 0但 buckets 数组还在内存没还给运行时delete只把槽位标记为空并递减count桶数组本身不会收缩。Go 的 map 没有自动缩容机制。如果 map 经历过一次流量高峰又回落内存会一直占着。真需要释放只能重新make一个新 map 把还在用的 key 搬过去或者直接丢弃整个 map 让 GC 回收。三种并发方案怎么选方案一sync.RWMutex 原生 map通用首选typeSafeMapstruct{mu sync.RWMutex mmap[string]int}func(s*SafeMap)Get(kstring)(int,bool){s.mu.RLock()defers.mu.RUnlock()v,ok:s.m[k]returnv,ok}func(s*SafeMap)Set(kstring,vint){s.mu.Lock()defers.mu.Unlock()s.m[k]v}读多写少场景的首选。读锁之间不互斥并发读性能很好代码直白行为可预测。绝大多数场景用它就够了。方案二sync.Map别滥用sync.Map内部做了读写分离用read只读副本无锁访问dirty需要加锁两层结构把读操作的开销降到最低。但它只在两种场景下真的更快key 写入一次、之后只读比如配置缓存、初始化后不再变的表多个 goroutine 各自读写互不相交的 key 集合。如果你的场景是写多或者key 频繁增删sync.Map反而比RWMutex map更慢——因为每次 miss 都要加锁穿透到 dirty还要维护 miss 计数和 dirty 提升逻辑。另外sync.Map丧失了类型安全和len()的 O(1) 能力要Range遍历计数。不要因为它是标准库提供的并发 map就默认选它。方案三分片加锁高并发写把 key 哈希到 N 个分片每个分片一把锁锁竞争降到 1/NtypeShardedMapstruct{shards[]*SafeMap}func(s*ShardedMap)shardOf(kstring)*SafeMap{h:fnv.New32a()h.Write([]byte(k))returns.shards[int(h.Sum32())%len(s.shards)]}适合写操作非常密集的场景比如高频计数器。代价是实现复杂度上升且跨分片操作比如求全量大小需要锁住所有分片。选型速查场景推荐方案读多写少通用sync.RWMutex map写后基本只读配置、字典表sync.Map多 goroutine 读写不相交的 keysync.Map写操作密集分片加锁只在启动时写、之后只读不加锁用闭包或 init 保证排查速查表现象原因处理fatal error: concurrent map writes多个 goroutine 同时写加锁或换sync.Mapfatal error: concurrent map read and map write一边读一边写同上recover兜不住fatal error不是panic只能从源头修无法兜底偶尔读到错值但不崩并发读写未命中检测go test -race定位内存删完不降map 不缩容重建 map 或丢弃用了sync.Map反而变慢写多场景不适合换回RWMutex map小结关于 Go map 的并发记住这四条map 并发读写会fatal error且无法recover—— 这不是 panic进程直接死没崩 ≠ 安全—— 检测依赖时序不崩的时候你可能正在读脏数据用-race判断根因是渐进式扩容搬迁—— 搬迁期间新旧桶并存、由nevacuate维护进度并发写会直接破坏这个状态机默认选sync.RWMutex map——sync.Map只在写后只读或key 不相交时才真的更快别默认用它。上一篇[我以为 append 是复制结果改了原数组Go 切片的底层数组共享与扩容规则]下一篇预告goroutine 泄漏的四个真实场景以及如何用 pprof 一次定位。