Go 数据竞争排查：读懂内存模型与 Race Detector

数据竞争不是“多协程同时运行”，而是两个 Goroutine 并发访问同一内存位置，至少一个是写，并且缺少明确同步。它可能只在特定核数、流量和调度时序下出现，因此本地跑几次没报错不能证明代码安全。

先建立 happens-before 思维

Go 内存模型关心的是一个操作的结果何时对另一个操作可见。锁的解锁与后续加锁、Channel 的发送与对应接收、Once.Do 完成与后续调用、原子操作之间，都可以建立同步关系。仅仅“这段代码通常先执行”不构成保证。

典型错误是并发修改普通 Map：

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

func (c *Cache) Get(key string) (string, bool) {
    c.mu.RLock()
    defer c.mu.RUnlock()
    value, ok := c.m[key]
    return value, ok
}

锁保护的不是某一行代码，而是一份不变量。读取两个相关字段时也必须处于同一临界区，否则可能得到从未真实存在过的组合状态。

正确使用 Race Detector

先覆盖单元和集成测试：

go test -race -count=1 ./...

仅有单元测试不够，可以构建带检测器的预发布二进制并跑真实流量：

go build -race -o app-race ./cmd/app
GORACE='halt_on_error=1 strip_path_prefix=/workspace/' ./app-race

Race Detector 只能发现实际执行到的竞争路径。提升覆盖率比反复运行同一小测试更有效：增加并发度、随机化操作顺序、覆盖超时与取消、在多核环境执行，并让测试持续足够久。

报告中通常包含两次冲突访问的栈，以及创建相关 Goroutine 的栈。修复时从共享对象的所有权入手，不要只在报告行附近随手加锁。

高频问题清单

共享切片

两个切片可能拥有同一底层数组。即使变量名不同，并发 append 或修改元素仍可能竞争。跨协程传递前做深拷贝，或者明确由单一 Goroutine 持有。

循环与闭包

闭包捕获的变量可能在下一轮被修改。现代 Go 已改善常见循环变量语义，但外部复用变量、指针字段和可变对象仍需要检查。

Channel 关闭

通常由发送方关闭 Channel，而且应只有一个关闭者。接收方关闭会让并发发送触发 Panic。多个生产者场景可用 WaitGroup 等待后由协调者统一关闭。

原子变量

atomic 适合独立计数器、指针替换或明确的无锁算法。若业务状态包含多个字段，Mutex 往往更清晰。把每个字段都改成原子操作，仍不能保证跨字段不变量。

修复优先级

  1. 能移除共享状态就移除，通过参数和返回值传递数据。
  2. 能确定单一所有者，就通过 Channel 发送命令而非共享对象。
  3. 状态简单且读写频繁时，用 Mutex 明确临界区。
  4. 只有经过基准和正确性证明，才考虑原子或无锁结构。

修复后不仅要让 -race 不再报警，还要添加能够稳定覆盖原问题的回归测试。对于共享状态，代码注释应说明“哪个锁保护哪些字段”，比泛泛写一句“并发安全”更有价值。

参考资料