Go 基准测试用 b.Cleanup 释放资源会不会算入基准耗时

我第一次把临时目录交给基准测试时，担心的是一个很实际的问题：如果用 b.Cleanup 删除目录、关闭连接，这些释放动作会不会被算进最后的 ns/op？答案是：清理回调的执行时间不计入基准耗时。Go 会在基准函数结束并停止计时后运行清理回调。

但有一个容易漏掉的细节：调用 b.Cleanup(func() { ... }) 进行“登记”的动作发生在基准函数内部。如果把登记放进被测循环，登记本身仍属于被测代码；回调真正执行的释放动作则在计时结束后完成。

官方地址：https://pkg.go.dev/testing#B.Cleanup

可以用 b.Cleanup 管理一次基准运行结束后的资源释放，不必为了排除清理耗时再手动调用 b.StopTimer。真正需要关注的是资源创建和回调登记放在了哪个位置。

先把三个时间点分开

一个基准函数里至少有三个不同概念：资源创建、清理回调登记、清理回调执行。它们可能写在相邻的几行，却不属于同一个时间边界。

• 资源创建：如果写在 b.Loop 或 b.N 循环里，通常会进入基准测量；如果写在循环前，则可以作为一次性准备。
• 回调登记：b.Cleanup 这一行本身是基准函数代码，放在循环内就会重复登记并产生登记成本。
• 回调执行：基准函数返回后，testing 包停止计时，再调用登记的清理函数，这段释放时间不会折算成 ns/op。

所以不能只看到“资源释放写在 Cleanup 里”就断言整段代码都不计时。准确的说法是：回调登记可能计时，回调执行不计时。

b.Cleanup 什么时候真正被调用

官方文档把 Cleanup 定义为：在测试或子测试及其所有子测试完成后调用注册的函数，而且多个回调按后注册先调用。对基准来说，可以把它理解为“一次基准运行的收尾钩子”，而不是每次循环迭代都会触发的函数。

func BenchmarkDecode(b *testing.B) {
	// 资源在被测循环前创建，只准备一次。
	cache := newDecodeCache()

	// 回调登记只发生一次；回调会在本次基准函数结束后执行。
	b.Cleanup(func() {
		// 释放动作不属于 ns/op 的计时区。
		cache.Close()
	})

	for b.Loop() {
		// 这里只放需要比较性能的解码动作。
		_ = cache.Decode(samplePayload)
	}
}

这段写法的重点不在于“Cleanup 能自动释放一切”，而在于所有权清楚：基准函数创建 cache，同一层登记对应的关闭动作，测试框架负责在基准结束时调用它。回调里不要再依赖一个已经被循环反复改写的临时状态。

为什么清理时间不进入 ns/op

从实现顺序看，一次基准运行会先重置计时器、启动计时器，调用用户的基准函数；函数返回后，testing 包调用 StopTimer，随后在延迟收尾逻辑中运行清理回调。因此 cache.Close() 的墙上时钟时间不会加入本次 BenchmarkResult 的 duration。

这也解释了为什么清理回调里即使有删除目录、关闭文件或等待连接退出，最终的 ns/op 仍主要反映被测函数。若希望观察完整测试生命周期的耗时，应另行记录测试流程；不要把基准的 ns/op 当成“创建加测量加释放”的总耗时。

登记放进循环会发生什么

下面这种写法通常不是想要的结果：

func BenchmarkBad(b *testing.B) {
	for b.Loop() {
		resource := openResource()

		// 每次迭代都登记一个回调，登记成本也在计时区内。
		b.Cleanup(func() {
			// 回调不会在本轮迭代结束时执行。
			resource.Close()
		})

		// 这里的操作与资源创建成本会一起进入测量。
		useResource(resource)
	}
}

这里有两个问题。第一，循环每执行一次就新增一个 Cleanup 回调，回调不会在本轮迭代结束时执行，资源可能一直积累到本次基准运行结束。第二，openResource 和 b.Cleanup 的登记成本都混入了被测区，结果不再只代表 useResource。

如果资源确实是“每次迭代都要新建并释放”，应在循环体内显式释放，或者把释放逻辑封装在一次迭代函数里；b.Cleanup 更适合一次基准运行、一次子基准或一次测试作用域的收尾。

b.Loop 和传统 b.N 怎么摆放资源

新代码优先使用 b.Loop。它在第一次进入循环时重置计时器，在返回 false 时停止计时器，所以循环前的准备和循环后的普通清理不会进入测量。

func BenchmarkEncode(b *testing.B) {
	// 一次基准运行只准备一份不可变输入。
	input := loadFixture()
	b.Cleanup(func() {
		// 这里释放与本次基准运行绑定的资源。
		input.Close()
	})

	for b.Loop() {
		// b.Loop 里的工作才是主要比较对象。
		_ = encode(input.Bytes())
	}
}

传统写法也遵循同一个原则：

func BenchmarkEncodeN(b *testing.B) {
	// 初始化和 Cleanup 登记放在 b.N 循环外。
	input := loadFixture()
	b.Cleanup(func() {
		// 回调在本次基准运行结束后释放输入资源。
		input.Close()
	})

	for i := 0; i 

b.Loop 的好处是它会处理循环规模和计时边界；使用 b.N 时，准备工作仍然可以放在循环外，但需要自己留意不要在每轮中重复创建本来只需一次的资源。

defer、b.Cleanup 和手动 Close 怎么选

我自己的取舍是：资源与一次基准运行绑定时用 b.Cleanup；资源与每次迭代绑定时显式释放；需要读取 Close 错误或在中途切换资源时，不把责任全交给 Cleanup。无论选哪种方式，都先问一句“这份资源应当活多久”，再决定写法。

最后记住这三个判断

1. 回调执行不计入 ns/op：基准函数结束后，计时器已经停止，Cleanup 负责做作用域收尾。
2. 回调登记可能计时：登记语句位于基准函数内，放进循环会增加被测成本并积累回调。
3. Cleanup 不是每轮 defer：需要逐轮释放的资源应在循环内处理，需要一次性收尾的资源才适合用 b.Cleanup。

相关问题

• b.Cleanup 会按什么顺序执行？多个回调按后注册先调用，适合按依赖倒序登记释放动作。
• 在 Cleanup 里调用 b.StopTimer 有必要吗？通常没有必要，因为基准函数返回后框架已经停止计时。
• 为什么资源创建放在循环外？这样测量结果更接近目标操作，而不是每次迭代的初始化、分配和释放总和。