Go 并发读写 map 为什么有时直接崩溃而不是数据竞争报告

因为你看到的是 Go runtime 针对普通 map 的并发访问保护，不是 race detector 的输出。普通 map 不支持无同步的并发读写；当运行时在一次 map 读写交叠中检测到冲突，会直接以 fatal error: concurrent map read and map write 终止进程。官方 map 说明见 https://go.dev/blog/maps。

最重要的结论：runtime fatal 与 -race 是两套机制。没有用 -race 构建就不会有竞争报告；即使用了 -race，进程也可能先命中 map 的 fatal 检查。

处理优先级：先停止并发写入或把访问收口到同一把锁，再用 go test -race ./... 扩大测试覆盖。不要依赖 recover，也不要把重试当成修复。

先区分两套机制

第一套是 runtime 对 map 操作的专用检查。当前 Go runtime 的 map 实现会在写入期间维护内部状态；另一个读或写操作观察到冲突状态时，可能触发 fatal。它的目标是避免程序在已经不可信的 map 状态上继续运行，不是为你生成完整的数据竞争分析报告。

第二套是 race detector。只有通过 go test -race、go run -race 或 go build -race 生成的程序才带竞争检测插桩。它会在冲突路径实际执行时输出 WARNING: DATA RACE、两次冲突访问的调用栈以及 goroutine 创建位置。官方说明见 https://go.dev/doc/articles/race_detector。

快速判断你看到的是哪一种输出

如果线上二进制不是用 -race 构建的，就只能期待 runtime 自己的错误或业务异常，不可能凭空出现 race detector 报告。另一方面，runtime 的 map 检查也不是通用竞争检测器：它只针对 map 内部的特定并发状态，不能证明程序的其他共享变量没有数据竞争。

为什么有时直接崩溃，有时又像没事

并发错误依赖真实执行时序。同一份代码在一次运行中，读写可能恰好错开；另一次运行中，读操作正好撞上写操作，于是 runtime 的检查被触发。goroutine 数量、CPU 核数、请求压力、GC、日志和测试顺序都可能改变这个时间窗口。

这也解释了为什么“本地跑过很多次”不能作为安全证明。没有触发 fatal，只代表本次调度没有撞中检查点；没有出现 WARNING: DATA RACE，还可能是因为根本没启用 -race，或者带插桩的测试没有覆盖那条路径。

即使带了 -race，runtime map fatal 也可能先终止进程。不要把“没有看到竞争报告”误解成“不是数据竞争”，更不要依赖两种机制的先后顺序。

处理步骤：先把普通 map 的访问收口

最直接的修复是把 map 和锁封装在同一个类型中，所有读写只能通过方法进入。不要在部分调用点加锁、其他调用点仍直接访问字段；只要存在一个旁路，问题就没有消失。

package counter

import "sync"

type Counter struct {
    mu sync.RWMutex
    m  map[string]int
}

func New() *Counter {
    return &Counter{m: make(map[string]int)} // 初始化后不向外暴露底层 map
}

func (c *Counter) Get(key string) (int, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock() // 读锁覆盖完整的查询过程

    value, ok := c.m[key]
    return value, ok
}

func (c *Counter) Inc(key string) {
    c.mu.Lock()
    defer c.mu.Unlock() // 写锁覆盖读取旧值和写回新值

    c.m[key]++
}

Inc 必须使用写锁，因为 c.m[key]++ 是读旧值、计算、写回的复合操作。不能先用读锁取值，再释放后用写锁写回；那会破坏操作的原子性。复制 map 引用也不能隔离并发，因为多个变量仍指向同一张底层表。

用 -race 找到所有旁路调用

修复后在测试、压测或预发布环境运行带竞争检测的程序。race detector 只会报告实际执行到的竞争，因此应覆盖故障请求、定时任务、热更新、缓存淘汰和关闭流程，而不是只跑一个最短单元测试。

# 对全部包运行启用竞争检测的测试
go test -race ./...

# 构建带竞争检测的二进制，使用接近生产的负载执行
go build -race -o app-race ./cmd/app
./app-race

看到报告后，先找两组冲突访问栈，再检查它们是否经过同一把锁。常见根因包括：后台刷新 goroutine 替换缓存，HTTP 请求同时读取；测试并行执行却共享包级 map；一个方法加了锁，但另一个辅助函数直接遍历 map；锁保护了 map 本身，却没有保护与 map 共同维护的计数器或索引。

三种同步方案怎么选

• 普通 map 加 sync.RWMutex：默认选择。适合需要类型安全、复合操作、批量遍历或多个字段共同维护不变量的场景。
• 单 goroutine 所有权加 channel：适合状态天然由事件循环驱动的服务。所有修改和查询请求都发给唯一所有者，代价是要设计请求、响应和退出协议。
• sync.Map：适合写一次读多次，或不同 goroutine 主要操作彼此独立键的专门场景。标准库文档明确说明，大多数代码仍应优先使用普通 map 配合锁，以获得类型安全并更容易维护不变量。

无论选哪一种，关键都是建立唯一、可审计的同步边界。把普通 map 换成 sync.Map 不能自动修复跨多个键或多个字段的业务原子性。

回滚路径与告警确认

如果线上正在崩溃，最快的安全回滚通常是关闭并行刷新、把写入降为单 worker，或回退到所有访问都经过同一把互斥锁的版本。不要尝试捕获这个 fatal 后继续服务：它不是普通业务 panic，程序也不应在共享状态可能损坏后继续运行。

发布修复后至少确认三件事：进程重启计数不再增加；日志中不再出现两类 concurrent map fatal；带 -race 的集成测试覆盖到原故障路径且没有新报告。若只能确认“线上不崩了”，还不足以证明所有竞争已经清除。

复盘清单

• 普通 map 是否被封装，调用方能否绕过同步方法直接访问？
• 所有读取、写入、删除、遍历和长度判断是否遵守同一同步协议？
• 复合操作是否在一次锁持有期间完成，而不是拆成多个步骤？
• 测试是否用 -race 运行，并覆盖原故障负载和后台 goroutine？
• 是否错误依赖 recover、重试、调低并发或“多跑几次没复现”？

最终判断很简单：fatal error: concurrent map read and map write 是 runtime 发现普通 map 的危险交叠后主动终止；WARNING: DATA RACE 是启用 -race 后的动态检测报告。两者都指向同一个工程动作——为共享状态建立完整同步边界。