Go 数据竞争只在压测出现：把 -race 接入高覆盖测试并读懂报告

如果数据竞争只在压测中出现，先不要把它当成“压测不稳定”。更常见的原因是普通测试没有同时覆盖两个访问者，或者测试虽然启动了 goroutine，却没有让它们真正触达同一份可变状态。把 go test -race 放进高覆盖测试，再按报告里的读写访问栈定位，通常比盯着业务断言更快。

实用结论：-race 只能报告运行过程中实际发生的竞争，所以关键是扩大并发场景覆盖；报告出现后先找同一共享变量的读栈和写栈，再回溯 goroutine 创建位置。修复动作应落在共享状态的同步边界或所有权边界上。

先判断：为什么本地测试通过而压测暴露竞争

数据竞争的判定点不是“结果错没错”，而是多个 goroutine 是否在没有合适同步的情况下访问同一内存位置，且至少一方会写。比如一个缓存用普通 map 保存结果，读取请求与刷新请求恰好并发执行，单线程单次测试很容易全部通过；压测改变了调度时机，才让这两个访问重叠。

因此，-race 的适用边界是“可执行路径上的并发内存访问”。它不会证明所有路径都安全，也不会代替业务正确性测试。下面的关系图把测试覆盖边界与共享状态边界分开，便于判断到底是测试没触发，还是代码确实缺少同步。

图1：数据竞争的关键不在于某次断言是否通过，而在于多个并发访问者是否共同触达未同步的共享状态。

把 -race 接进高覆盖测试

先在项目根目录执行最小命令：

go test -race ./...

它会重新构建带检测能力的测试程序，然后运行各包测试。若仓库测试本身没有并发场景，还要补一个能稳定制造访问重叠的用例。例如下面的缓存类型把读写都指向同一张 map：

type Cache struct {
    data map[string]string
}

func (c *Cache) Put(key, value string) { c.data[key] = value }
func (c *Cache) Get(key string) string { return c.data[key] }

func TestCacheConcurrentAccess(t *testing.T) {
    c := &Cache{data: make(map[string]string)}
    var wg sync.WaitGroup
    wg.Add(2)
    go func() { defer wg.Done(); c.Put("region", "cn") }()
    go func() { defer wg.Done(); _ = c.Get("region") }()
    wg.Wait()
}

这个例子不是为了依赖某个固定报错顺序，而是为了让读写共享状态进入同一测试窗口。CI 中可以把它作为普通测试的一部分；本地排障时还可以缩小范围：

go test -race -run 'TestCacheConcurrentAccess' ./internal/cache

检测版测试通常会明显变慢并占用更多内存，不能直接拿它的耗时和普通测试做性能结论。更合适的工程做法是：日常提交跑关键高覆盖包，定时任务跑 ./...，大型压测则先用压测请求把可疑路径触发，再回到可重复的测试用例。

读报告时先看两条访问栈

报告以 WARNING: DATA RACE 开头时，先记录它指向的共享变量和源代码行，不要只看最后的退出码。通常会看到一段读访问栈、一段写访问栈，随后各自带有 goroutine 创建信息：

WARNING: DATA RACE
Read at 0x... by goroutine 8:
  ... cache.go:18
Previous write at 0x... by goroutine 7:
  ... cache.go:14
Goroutine 8 (running) created at:
  ... handler_test.go:32
Goroutine 7 (finished) created at:
  ... refresher_test.go:21

读栈和写栈回答“哪两次访问冲突”，创建栈回答“这两个 goroutine 从哪里被启动”。把两条访问栈拉回同一个字段、map 或切片后，再判断应该加互斥锁、使用原子操作、复制数据，还是把状态所有权收回单个 goroutine。不要看到创建栈就直接修改启动代码，它往往只是线索，不是竞态发生的位置。

图2：读报告先找同一共享变量对应的读写访问栈，再沿 goroutine 创建栈回溯并发来源。

需要把报告分文件保存时，可以设置 GORACE，例如 GORACE="log_path=./race-report strip_path_prefix=$PWD"。日志目录应由 CI 工作区管理，避免把旧报告误当成这次测试的结果；若希望第一次报告就停止，可按官方支持的选项配置 halt_on_error=1。

修复后的复测与边界清单

修复的目标不是让报告暂时消失，而是让共享状态的访问规则变得明确。对缓存 map，最小修复通常是让 Put 和 Get 共用一把 sync.RWMutex；如果值本身是不可变快照，也可以在发布新快照时用原子替换。选择哪一种取决于读写比例、对象生命周期和调用方是否会继续修改返回值。

改完后按同一顺序复测：

• 先运行针对性用例：go test -race -run 'TestCacheConcurrentAccess' ./internal/cache。
• 再运行包级和仓库级高覆盖测试：go test -race ./...。
• 若只有压测能触发，保留一个更小的回归用例，并在 CI 中固定执行。
• 若报告仍出现，比较新的读写栈是否已经换到另一个共享字段，不要只按“出现次数”判断修复完成。

最后做一次边界判断：未执行到的代码不会产生报告；进程外存储、网络协议语义和数据竞争也不是同一类问题；检测通过只表示这组运行没有观察到竞争。把覆盖范围、测试命令和已知未覆盖路径写进变更说明，结论才可复查。

常见问题

为什么加了 -race 还是没有报告？

最常见是测试没有同时进入冲突访问，或只覆盖了安全分支。补充并发回归用例、增加输入组合，再用 -run 重复执行该用例，比盲目提高压测并发数更容易定位。

能不能只在生产压测时开启？

可以用于隔离环境，但检测版程序有额外开销，不应当作正常生产性能基线。更稳妥的是用压测发现路径，再将最小触发条件沉淀为可重复的 go test -race 用例。

报告里的创建栈是不是根因？

不是。创建栈说明 goroutine 的来源；根因通常要回到同一共享变量对应的读访问和写访问，检查它们之间缺少的同步或所有权约束。

参考资料：Go 官方 Race Detector 文档。