Go race 为什么加参数后变慢很多

给 Go 命令加上 -race 后变慢很多，通常是正常现象，不是业务代码突然失去了优化。Race detector 会为内存访问和同步关系加入运行时跟踪；官方文档给出的典型范围是内存增加约 5–10 倍、执行时间增加约 2–20 倍，具体数值取决于程序的共享数据、goroutine 数量和 workload。

官方地址：https://go.dev/doc/articles/race_detector

先看清 -race 改变了什么

go test -race、go run -race 或 go build -race 会产出带竞态检测能力的构建。程序运行期间，检测器要观察不同 goroutine 对共享内存的访问，并结合锁、channel 等同步关系判断是否存在未排序的读写。

# 用同一个测试包分别建立普通基线和竞态检测基线；两条命令的输入、测试集合和次数要保持一致
go test -count=1 ./... && go test -race -count=1 ./...

因此第二条命令的目标不是“跑得和第一条一样快”，而是用更高成本换取数据竞争线索。即使没有报告，运行时间也不能据此推断线上服务的延迟。

为什么 CPU 和内存会一起上升

普通构建只执行业务访问；竞态检测构建还要记录访问上下文、维护每个 goroutine 的历史，并在同步点进行关系判断。共享内存访问越密集、并发度越高，额外工作越明显。频繁创建 goroutine、短小循环和高吞吐 channel 场景，往往比单线程计算更容易放大差异。

内存变大也不只来自业务对象。官方文档指出，检测器会保存额外的访问历史；history_size 默认值为 1，每个 goroutine 的历史规模按 32K * 2**history_size 计算。长期 goroutine 中频繁使用 defer 和 recover 还可能带来额外分配，这类开销不一定出现在 runtime.ReadMemStats 或 pprof 的常规输出里。

这解释了一个常见误判：不能因为 -race 下 RSS 变大，就直接断言业务泄漏；应先区分检测器固定成本、测试 workload 放大的历史成本和真实对象未释放。

用同一 workload 比较，别拿启动时间下结论

如果要判断“慢了多少”，至少固定三件事：测试数据、并发度和执行次数。优先比较稳定的业务阶段，例如批量请求、并发读写或一组基准函数；不要把第一次编译、缓存命中和测试二进制启动混在一起。

实际排查时，可以先让 -race 覆盖并发测试、集成测试和关键路径子集，再用普通构建做性能基线。两者承担的任务不同：前者回答“是否存在可观察的数据竞争”，后者回答“正常部署形态的性能如何”。

GORACE 只调整排查边界

# 首个报告后退出并保存带进程号的报告；history_size 只在恢复栈失败时谨慎增加
GORACE="log_path=./race-report halt_on_error=1" go test -race ./...; GORACE="history_size=2 strip_path_prefix=$(pwd)" go test -race ./...

log_path 适合 CI 保存报告，halt_on_error=1 适合先拿到最小复现，strip_path_prefix 用来缩短路径。遇到 “failed to restore the stack” 时才考虑增大 history_size，因为它会进一步增加每个 goroutine 的历史空间。不要靠调小参数把检测器变快后，再把结果当成完整覆盖。

相关问题

生产环境应该一直开启 -race 吗？

通常不应该把它当作生产性能构建。更合适的边界是 CI、预发布集成测试和可控的压测子集，线上仍用普通构建并保留独立的并发测试。

加了 -race 后测试超时怎么办？

先确认测试超时是否仍按普通构建的预算设置，再拆分 workload 或提高测试专用预算；不要因为超时就删除并发覆盖，也不要把普通构建的耗时阈值直接套用。

没有报告是不是说明没有数据竞争？

不是。检测器只能观察实际执行到的访问路径；要提高发现概率，还需要扩大测试输入、并发交错和集成场景。