Go benchmark b.N 变化时为什么不能缓存一次结果

我第一次遇到这个问题，是在整理一组 Go 基准测试时发现：同一个 benchmark 函数里明明写了循环，结果却像只测了一次。关键不在于 b.N “变得不稳定”，而在于它本来就不是业务输入，而是 testing 包为了得到可靠计时而动态调整的迭代次数。

所以，b.N 变化时不能把一次调用得到的结果缓存成后续调用的答案。每次 benchmark 调用都应该让目标操作按当前的 b.N 运行；如果要测缓存命中，也要把“缓存命中”明确当成被测操作，而不是让缓存绕过整个循环。

一、先分清 b.N 是测试输入还是固定配置

Go 的传统 benchmark 约定是：函数体内需要执行目标代码 b.N 次。testing 包会多次调用这个函数，并调整 b.N，直到运行时间足以形成可用的平均值。也就是说，第一次调用得到的 b.N 只对那一次调用负责，不能被保存后复用。

可以把一次 benchmark 看成两个边界：外层是测试框架决定的调用与迭代次数，内层是我们希望计时的被测操作。只要代码依赖“第一次算出的结果”，这两个边界就被混在了一起。

二、定位一次缓存造成的计数失真

下面这种写法看起来像是在避免重复计算，实际上会让 benchmark 失去含义。第一次调用可能填充缓存，后续调用只返回旧结果；当 b.N 已经变大时，循环次数和真实执行次数就不再相等。

var cached []byte

func BenchmarkDecodeBad(b *testing.B) {
	for i := 0; i 

这段代码测到的更接近“第一次填充缓存加上大量切片读取”的混合成本，而且全局状态还会跨 benchmark 调用存活。若结果对象可变，后续调用甚至可能读到已经被上一次测试改过的状态。

三、把每次操作放回 b.N 循环

如果目标是测每次解码，就让每次迭代都调用解码函数，并把返回值交给一个不会被编译器轻易消掉的使用点。昂贵的固定输入可以在循环外准备；如果准备动作发生在计时开始后，就用 ResetTimer 把计时边界重新放到循环前。

var decodeSink []byte

func BenchmarkDecode(b *testing.B) {
	input := append([]byte(nil), sampleInput...)
	// 准备工作不属于本次解码耗时，重新开始计时前先清除准备阶段。
	b.ResetTimer()
	for i := 0; i 

这里的重点不是把变量名改成不同形式，而是保证当前 b.N 次循环与当前测量目标一一对应。若采用 Go 1.24 及更新版本，也可以用 for b.Loop() 表达可重复的 benchmark 循环，减少手工处理迭代总数时的误用。

四、按测量目标决定缓存放在哪里

缓存并非不能出现在 benchmark 中，关键是缓存代表什么。先把目标写成一句话，再决定缓存的位置：

例如要测命中路径，可以在 ResetTimer 前完成一次填充，然后在 b.N 循环中重复调用“读取缓存”的函数。不要用 sync.Once 包住整个被测动作，否则测到的只是一次构建和很多空转。

五、用命令和清单复查结果含义

复查时先缩小测试范围，再改变测量时长和重复次数。命令本身不负责修复错误，但能帮助你观察代码是否把目标动作放在每轮循环中：

# 只运行 benchmark，不运行普通测试，并重复整个 benchmark 过程。
go test -run '^$' -bench '^BenchmarkDecode$' -benchtime=200ms -count=5

# 需要检查分配时，使用 testing.B 的分配报告选项。
go test -run '^$' -bench '^BenchmarkDecode$' -benchmem

• 确认循环上界使用当前的 b.N，没有缓存第一次的迭代次数。
• 确认缓存命中、缓存构建和无缓存基线是不同 benchmark 或不同子场景。
• 确认准备、清理和结果消费没有意外占用计时；必要时检查 ResetTimer、StopTimer。
• 确认结果不会被编译器完全删除，也没有通过全局状态跨调用污染下一轮。

相关问题

为什么 benchmark 函数会被调用多次？

因为 testing 包需要调整 b.N，让目标代码运行足够长，再计算每次操作的指标。多次调用是测量机制的一部分，不是异常重试。

把输入数据放在循环外是不是也算缓存错误？

不一定。固定输入通常是合理的准备；只要被测函数仍在每次 b.N 迭代中执行，并且准备阶段没有混进计时即可。

什么时候可以使用 sync.Once？

当测试目标明确是“一次性初始化”的成本时可以使用。若目标是每次操作、缓存命中或平均请求成本，就不要让 sync.Once 越过被测循环。

新 benchmark 是否应该直接改用 b.Loop？

Go 官方建议新 benchmark 优先考虑 B.Loop，它能减少对总迭代次数和计时边界的手工假设；维护旧代码时仍应先修正缓存与状态污染问题。