Go go test -race 为什么能发现共享变量数据竞争

go test -race 能发现共享变量数据竞争，不是因为它提前推演了所有代码路径，而是因为带 -race 构建的测试程序会在运行时记录实际发生的内存读写，再根据 goroutine 之间是否存在同步关系判断冲突。两个 goroutine 同时访问同一变量，且至少一次是写入；如果这两次访问之间没有明确的 happens-before 关系，就可能出现 WARNING: DATA RACE。

race detector 报告的是“这次运行中实际观测到的未同步冲突”，不是“程序所有并发问题都已解决”。修复后仍要让测试覆盖共享状态的不同执行路径。

共享变量为什么会构成数据竞争

下面的计数器看起来很简单，但两个 goroutine 都会读、改、写同一个 total。total++ 不是不可分割的同步操作，至少包含读取旧值和写回新值；如果两个 goroutine 交错执行，结果可能丢失，检测器也会把这对访问列为冲突。

var total int

func add() {
    // 读旧值、加一、写回 total，整个复合操作没有锁保护。
    total++
}

func TestTotal(t *testing.T) {
    var wg sync.WaitGroup
    wg.Add(2)
    // 两个 goroutine 共享 total，但 WaitGroup 只等待结束，不保护 total。
    go func() { defer wg.Done(); add() }()
    go func() { defer wg.Done(); add() }()
    wg.Wait()
}

这里的 WaitGroup 只表达“什么时候都结束”，并没有把 add 内部的读写串行化。等待发生在冲突访问之后，所以不能消除竞争。Go 内存模型把未被同步关系排序的读写视为数据竞争，不能用“通常能得到 2”来证明代码正确。

race detector 到底依据什么判断

它关注的是运行时访问，而不是变量名里有没有 shared。在带 -race 的构建中，普通内存访问会被插入检测信息；互斥锁、通道、原子操作等同步原语则提供排序线索。若同一内存位置出现并发读写或写写，且至少一方不是原子访问，同时两者没有 happens-before 关系，报告就有了依据。

因此，下面三件事要分开理解：

• 实际执行：没有被测试或真实负载走到的分支，可能不会触发报告。
• 访问冲突：至少一方写入才是数据竞争；两个只读访问通常不是。
• 同步排序：锁、通道或正确使用的原子操作让访问具备明确关系，单纯等待测试结束不等于保护共享状态。

如何从 WARNING: DATA RACE 报告回到代码

报告通常先给出一处读或写的调用栈，再给出另一处冲突访问，最后补充相关 goroutine 是从哪里创建的。排查时先锁定共同的变量和字段，再问两处访问是否由同一把锁、同一条通道协议或同一组原子操作约束。创建栈的作用是告诉你并发边界，不代表创建位置就是根因。

想让日志更容易对应到本地代码，可以把路径前缀去掉，并把报告写到文件：

# 把 race 报告写入带进程号的文件，并缩短源码路径。
GORACE="log_path=/tmp/go-race/report strip_path_prefix=$(pwd)" go test -race ./...

如果报告提示测试没有触发竞争，先检查覆盖范围：可以增加会访问共享状态的测试，或用 go build -race 构建后在接近真实的负载下运行。开启 race 后变慢是正常现象，官方文档说明典型程序的内存和执行时间都会增加，因此不要把 race 构建直接当成生产性能基线。

修复时该选锁、通道还是原子操作

修复目标不是让报告消失，而是让共享状态拥有清楚的所有权和同步边界：

例如计数器只需要独立加一时，可以用原子操作；如果更新计数器还要同时修改余额、时间和审计字段，更适合用同一把互斥锁把整个不变量包住。修复后重新运行 go test -race ./...，再补一次不同调度和输入下的测试；一次绿色结果只说明这次覆盖到的执行没有报告竞争。

三个常见误区

加了 WaitGroup 就不会竞争吗？

不会。它主要协调 goroutine 的加入和结束，不能自动保护 goroutine 运行期间访问的变量。

只要测试通过就说明没有 race 吗？

不会。普通 go test 关注断言和错误返回；要检查数据竞争，需要明确使用 -race，并让测试实际走到并发访问。

race detector 报告为空就能上线吗？

不能这样推断。它依赖运行时覆盖，仍需结合代码审查、压力场景和明确的同步设计。把共享变量的所有读写收拢到可解释的边界，通常比反复重跑测试更可靠。