S09-A26 · `map` 并发写：为什么"崩的是运行时"，不是你的代码

一个缓存模块用 map[string]*Entry 存热点数据，多个 goroutine 读写。压测到一定并发，进程直接退出，日志只有一行 fatal error: concurrent map read and map write——没有 panic 栈，没有 recover 机会，因为它是运行时检测到的致命错误，不是普通 panic。

Go 的 map 有一条硬规则：并发写（或"写与读"同时）是"未定义行为"，而运行时会主动检测并中止进程。于是它不是"数据错乱"，是"进程退出".

1. 三种"并发访问"的后果

访问组合	后果
多 goroutine 只读	安全
一个写 + 其它读	可能 fatal
多个写	可能 fatal

第二项最容易被低估："我只在一个地方写"第二项的"误判"很常见："写只有一处"被理解成"不会并发"——**而"一处写"与"多处读"同时发生，就已经满足"并发 read/write".
——**而"读"也是并发的一部分，运行时不区分"谁先来".

2. "为什么是 fatal 而不是 panic"

项	说明
检测方式	运行时置"写标志位"，读写时检查
触发	检测到"标志位冲突"
结果	`throw` → 进程退出（`recover` 无效）

第三项的"证据"就是那行日志：fatal error: concurrent map read and map write——它是 throw 而不是 panic，所以"没有栈、没有 defer、recover 也拦不住".
第三项是"最要命"的：recover() 抓不到**——**于是"兜底"手段完全没有，只能"从设计上避免".

"读写分离的快照"是"高并发"的最优解，而它只有两个动作:

// 快照 + 原子替换（读无锁）
type Store struct{ p atomic.Pointer[map[string]*Entry] }
func (s *Store) Get(k string) *Entry { return (*s.p.Load())[k] }   // 无锁读
func (s *Store) Put(k string, e *Entry) {                          // 写：复制 + 替换
    old := *s.p.Load(); m := make(map[string]*Entry, len(old)+1)
    for kk, vv := range old { m[kk] = vv }; m[k] = e
    s.p.Store(&m)
}
// 判据：读远多于写（写要"复制整表"，O(n)）

3. "三种解法"的代价

解法	代价
`sync.RWMutex`	一把锁（简单，争用）
`sync.Map`	分片 + 原子（适合"读多写少"）
分片 map（sharding）	自己实现（最灵活）

第一项是"默认选择"：RWMutex 的"读锁"允许多读第一项的"实测"通常够用："读 95%、写 5%"时，RWMutex 的"读并发"几乎"线性"——**而"写 5%"意味着"每秒几万次里只有几千次抢写锁".
——于是"读多写少"时争用不大.

第二项的"反例"很具体："用 sync.Map 做计数器（每次请求 Load+Store）"——Store 会"写 dirty map"，于是"读也得过一遍"，比"分片 + 锁"还慢.
第二项要"看清前提"：sync.Map 为"键集合稳定、读远多于写"优化**——"写多"时它反而更慢.

4. "`sync.Map` 的三个适用条件

条件	说明
键"基本不增删"（或很少）	避免"dirty map 提升"
读远多于写	命中 `read` 分支（无锁）
元素"整体覆盖"而非"逐键改"	适合"配置/元数据缓存"

第三项最反直觉：sync.Map 的"写"要"复制/提升"，逐键频繁写会"很慢"第三项的"机制"是"两级结构"：read（无锁只读）+ dirty（加锁可写）——**"写"会"提升 dirty"，而"每次写新键"都可能"触发一次全量复制".
——于是"计数/累加"这类"逐键写"不适合它.

"分片"要"暴露一个好用的包装"，否则"调用方还得自己算下标":

// 三段"分片包装"（Get/Put/Delete 都是"先算片，再操作"）
func (s *Sharded) Get(k string) *Entry {
    sh := &s.m[s.idx(k)]; sh.mu.RLock(); defer sh.mu.RUnlock(); return sh.v[k]
}
func (s *Sharded) Put(k string, e *Entry) {
    sh := &s.m[s.idx(k)]; sh.mu.Lock(); defer sh.mu.Unlock(); sh.v[k] = e
}
// 判据：调用方"只看 Get/Put"，不接触锁与下标

5. "分片"的三种做法

做法	说明
按 key 哈希取模分 N 个 map	最常见（N=2^k）
按"业务维度"分（如租户）	利于"整片清理"
用"每 goroutine 一个本地 map + 汇总"	适合"计数"（最后合并）

第一项的"N 怎么定"有个实用口径："N = 2^k ≥ CPU 核数 × 2"——太大"内存与 miss 上升"，太小"仍争用"；而"2 的幂"让"取模"变成"位与".
第一项是"通用解法"："锁的粒度变成 1/N"**——而 N 通常"CPU 核数 × 2"就够.

// 三行"分片"（把一把锁拆成 N 把）
type Sharded struct { m [256]struct{ mu sync.RWMutex; v map[string]*Entry } }
func (s *Sharded) idx(k string) int { return int(fnv32(k) & 255) }
// 读：s.m[i].mu.RLock(); 写：s.m[i].mu.Lock()
// 判据：竞争激烈时，"分片"比"换 sync.Map"更可控

"race 检测"有成本，但它"只在测试环境"跑，代价可接受:

// 三种"跑 race"的方式
1 go test -race ./...            # 单测（推荐，CI 必跑）
2 go run -race main.go           # 本地复现
3 生产不开（-race 会显著变慢、内存翻倍）
// 判据：CI 里"必须有一份 -race 的流水线"

6. 排错：五种"map 并发问题"

现象	成因	处理方向
进程直接退出	并发读写	加锁/换结构
`recover` 抓不到	它是 fatal	靠设计避免
压测才崩	并发低时碰不到	压测必跑
CPU 高但吞吐低	锁争用	分片
`sync.Map` 更慢	写多	换回 `RWMutex`

"初始化后只读"这种情况，值得"用一个明确的类型"表达:

// 三段"只读表"（启动时构建，之后只读）
var table map[string]int          // 包级，仅在 init 里赋值
func init() { table = build() }    // 之后"只读"，无并发写
// 判据：有"任何"运行期写，就不能用这个模式

7. 边界：什么情况"不必加锁"

场景	为什么	做法
单 goroutine 独占	无并发	裸 map
"初始化后只读"	写发生在"启动期"	只读 map
用 channel 串行化访问	由 channel 保证	不必锁
用"不可变快照 + 原子替换"	读写分离	不必锁

第四项是"高并发"的常见技巧："整体替换一份新 map（原子指针）"——**读路径"无锁"，写路径"复制 + 替换".

8. 自测

三种并发访问组合里，哪一种"最容易被低估"？为什么"只在一个地方写"也会崩？
为什么它是 fatal 而不是 panic？recover() 为什么无效？
sync.Map 的三个适用条件是什么？"逐键频繁写"为什么不适合它？
"按 key 分片"如何降低争用？分片数怎么定？
"不可变快照 + 原子替换"为什么能"读路径无锁"？
判断"要不要加锁"的那个问题是什么？

补一句"成本"的账："加一把 RWMutex"的成本是"一行 + 一次 defer"，而"不加以至于崩"的成本是"一次线上事故 + 一次复盘"——这个比例说明，"并发 map"这件事"默认加锁"是唯一理性选择；而"要快"的正确路径是"分片"或"快照"，不是"赌时序".

而"赌时序"这件事，往往在"压测 50 并发"时躲过去、在"大促 5000 并发"时爆出来——而那时"复盘"要回答的第一个问题是"为什么没加锁"，而它没有好的答案。

所以"默认加锁"不是保守，是"成本最低的那条路"。

而"最低成本"这四个字，值得写进团队规范里。

9. 一句话总结

Go 的 map 并发问题是"进程级故障"，不是"数据级 bug"——所以它"不能被兜底"，只能"从设计上避免"。选型顺序很清楚：读多写少用 RWMutex（或"快照 + 原子替换"）、键集稳定且读极多用 sync.Map、争用激烈用"分片"；而"压测不跑并发"的团队，会在"上线后的第一个热点"遇到它。