Go benchmark 结果波动大如何固定测试条件

Go benchmark 结果忽高忽低时，先不要急着改业务代码。更可靠的做法是把测试条件固定成一份可复制的命令：让被测循环只包含目标操作，使用固定的 -benchtime、-count 和 -cpu，再避开编译、系统更新和其他高负载任务。这样得到的多次样本，才适合比较优化前后的差异。

基准测试不能把整台机器变成实验室，但可以把采样边界、并发度、运行时长和重复次数固定下来。先控制条件，再解释 ns/op 的变化。

• 计时边界：初始化、读取固定输入等准备工作不要放进被测循环。
• 采样参数：明确 -benchtime、-count、-cpu，不要每次凭手感改命令。
• 运行环境：记录 GOMAXPROCS、机器电源模式、后台负载和是否使用并行 benchmark。

先把 benchmark 写成可重复测量的单位

testing.B 的核心价值是定义一段稳定的测量边界。新代码可以用 b.Loop 表达被测循环，把固定输入和对象构造放在循环外；如果仍使用 b.N，则要确认计时器没有把准备工作算进去。下面的例子只比较字符串解析本身，输入在每次基准运行前准备好。

package parser

import (
	"strconv"
	"testing"
)

func BenchmarkParseUserID(b *testing.B) {
	input := "170golang-2026"
	b.ReportAllocs() // 同时观察分配次数，避免只看耗时。
	for b.Loop() {
		_, _ = strconv.Atoi(input[:4]) // 只把目标解析操作放入计时边界。
	}
}

不要在循环里重新生成随机字符串、读取文件或打印日志。它们会把输入准备、I/O 和调度成本混进同一个指标。若确实要测完整请求路径，应把这些成本写进测试目标，并在标题或注释中说明，不要把它误称为纯函数 benchmark。

用 go test 参数固定一组可比较样本

单次运行只是一条观测值。为了降低偶然调度和缓存状态的影响，可以把命令固定为同一组参数，再用 -count 取得多份样本：

# 固定目标 benchmark、单个 CPU 并发度，并重复采样 10 次。
go test -run '^$' -bench '^BenchmarkParseUserID$' -benchtime=2s -count=10 -cpu=1 ./...

# 只有在研究并发扩展性时，才显式比较多个 GOMAXPROCS 值。
go test -run '^$' -bench '^BenchmarkParseUserID$' -benchtime=2s -count=10 -cpu=1,2,4 ./...

-run '^$' 用来跳过普通测试，避免测试本身干扰这次采样；-bench 把范围收窄到目标函数；-benchtime 让每个样本有足够的测量时间；-count 让后续比较不依赖一次偶然结果。第二条命令不是“更稳定”的默认值，它是在回答并发度变化会怎样影响结果。

比较优化前后时，尽量保留同一条命令、同一份输入和同一台机器。可以把两次输出分别保存为文本，再交给 benchstat 做统计比较；不要看到一条 ns/op 变小就直接宣布优化有效。

把 GOMAXPROCS 和机器状态列入测试条件

-cpu 会为 benchmark 设置一组 GOMAXPROCS 值；如果代码内部还调用 runtime.GOMAXPROCS，就可能改变你以为固定的条件。普通单线程基准通常先从 -cpu=1 开始，研究并发路径时再把 1、2、4 等值作为明确的对照组。

同时记录这些容易被忽略的变量：

• 机器是否接电、是否处于省电模式，CPU 是否因温度降频。
• 后台是否有编译、容器、浏览器标签页、同步任务或杀毒扫描。
• 代码是否调用 b.RunParallel，以及 b.SetParallelism 是否改变了并发规模。
• 基准运行期间是否发生 GC、首次初始化、磁盘读取或网络访问。

这些因素不能靠 benchmark 参数全部消除。关键是把它们写进记录：例如“接电、CPU 空闲、GOMAXPROCS=1、同一提交、重复 10 次”。下一次结果异常时，先对照条件，而不是先改代码。

怎样判断波动来自代码还是环境

可以按下面的顺序解释样本：

最终应比较同一条件下的一组样本，而不是比较两次随手执行的单值。若差异没有超过自然波动范围，就先保留现状；若差异稳定出现，再回到分配、锁竞争或输入规模等更具体的指标。

常见问题

为什么加了 -count=10 结果仍然会波动？

-count 只增加重复样本，不会关闭后台任务、CPU 降频、GC 或系统调度。它要和固定的 -cpu、足够的 -benchtime 以及稳定的机器状态一起使用。

基准测试应该永远使用 -cpu=1 吗？

不是。单线程算法可以先用 -cpu=1 减少变量；并发算法则需要显式比较多个并发度。关键是不要把不同 GOMAXPROCS 的结果放在同一组样本里解释。

为什么不能只看一次最低的 ns/op？

最低值可能只是恰好避开了调度或后台负载。应保存多次结果，比较均值、离散程度和分配指标，再决定优化是否稳定。