go test benchmark 如何判断分配次数变多

如果一次优化让 benchmark 的 ns/op 变差，先不要直接下结论说“分配变多了”。判断 Go 基准测试是否真的产生了更多分配，应该同时看 allocs/op 和 B/op：前者是每次操作的分配次数，后者是每次操作分配的字节数。两项一起上升，才更像是被测路径新增了分配；只有耗时上升，则还可能是锁竞争、分支变化或测试输入不稳定。

下面把分配次数当成需要保护的性能资产，按“资产—路径—风险—控制—记录”的方式排查。示例只用于说明写法，图示是静态说明图，不是本机运行截图。

本文要点：用 -benchmem 或 ReportAllocs 打开分配统计；固定输入，避免把准备工作算进被测区间；用同一命令比较基线和改动后的 allocs/op、B/op。

先把“分配变多”变成可读指标

保护对象不是一个模糊的“性能”，而是每次操作的分配次数和分配字节数。go test 默认不会把这两列打印出来，可以在命令中加 -benchmem，或者只在某个 benchmark 中调用 b.ReportAllocs()。前者适合统一跑一组基准，后者适合把采集范围锁定到当前函数。

package textbench

import (
	"strings"
	"testing"
)

var benchmarkText = strings.Repeat("go benchmark ", 32)

func joinWords(s string) string {
	// 这里只保留一个明确的被测入口，避免把输入准备混进测量区间。
	return strings.TrimSpace(s)
}

func BenchmarkJoinWords(b *testing.B) {
	// 让测试框架报告 allocs/op 和 B/op，便于和基线逐列比较。
	b.ReportAllocs()
	b.ResetTimer()
	for i := 0; i 

# -benchmem 把每次操作的分配次数和字节数加入结果行
go test ./... -run '^$' -bench '^BenchmarkJoinWords$' -benchmem -count=5

# 保存同一命令的输出，便于与改动前结果并排记录
go test ./... -run '^$' -bench '^BenchmarkJoinWords$' -benchmem -count=5 > bench-after.txt

结果行中的 allocs/op 是分配次数除以操作次数，B/op 是分配字节数除以操作次数。不要只盯着一次运行的整数值；先确认命令、输入和编译条件相同，再比较多次运行中是否稳定地偏高。

按攻击路径排查额外分配

这里的“攻击路径”不是安全漏洞，而是任何可能把额外分配带入测量边界的代码路径。最常见的入口有四类：循环里重新构造输入；返回值逃逸到堆；格式化或日志把临时对象带进循环；并发 benchmark 的计数器、共享状态或同步结构改变了观测条件。

可以把排查拆成以下判断：

• 输入构造：把字符串、切片或请求对象的准备移到循环外；否则增加的可能是测试夹具分配，而不是业务函数分配。
• 结果逃逸：不要为了“使用返回值”把它追加到一个不断增长的全局容器；用局部黑洞变量保持结果可见即可。
• 格式化路径：基准循环中的 fmt.Sprintf、日志拼接或错误包装，可能是新分配的真正来源，应和核心调用拆成两个 benchmark。
• 并发路径：RunParallel 的结果要和串行基线分开看。并发计数或共享容器会引入同步成本，不能把它直接解释成单次操作的分配回归。

如果改动后只有 ns/op 上升，而 allocs/op 与 B/op 基本不变，应先把结论写成“耗时回归，分配证据不足”，不要把所有性能变化归因于堆分配。

把分配回归写成可审计的对照记录

分配次数变多的判断需要对照。建议每次记录基线提交、改动提交、Go 工具链、运行命令、输入规模、ns/op、B/op、allocs/op 和重复次数。记录不必很长，但要能回答“是不是同一条路径、是不是同一组输入、是哪一列变了”。

# 这是示例记录格式，不是运行日志
基线：allocs/op=1，B/op=16
改动：allocs/op=2，B/op=48
结论：分配次数和字节数均上升，进入代码路径排查
边界：输入构造已移出循环，未使用 RunParallel

若只想在代码中测一个函数的平均分配次数，可以使用 testing.AllocsPerRun，但要注意它会先进行一次预热，并在测量期间把 GOMAXPROCS 设为 1，返回后再恢复。因此它适合做窄范围的分配对照，不应和并发 benchmark 的结果直接混为一谈。

常见误区与最终检查

第一，allocs/op 是平均指标，不代表每一次调用都恰好发生相同次数的分配；第二，B/op 上升但 allocs/op 不变，可能是同样次数的分配对象变大；第三，单次运行的波动不能替代重复对照；第四，把准备、日志和结果收集写在循环中，会污染测量边界。

最终可以用这张清单收口：

1. 是否用 -benchmem 或 ReportAllocs 获得了两列内存指标？
2. 是否固定输入，并确认循环只覆盖被测操作？
3. 是否至少重复运行，并比较中位趋势而非单次结果？
4. 是否把串行、并发、格式化和核心调用拆开对照？
5. 是否记录了结论的证据列，而不是只写“感觉变慢”？

一句话总结：判断 Go benchmark 是否分配变多，先看稳定的 allocs/op 和 B/op，再沿输入、返回值、格式化和并发边界排查；只有指标和边界证据对得上，才把它记为真实的分配回归。

相关问题

为什么 B/op 变大但 allocs/op 不变？通常是分配次数没有增加，但单个对象或缓冲区容量变大，需要继续看返回对象和容量增长。

benchmark 中应该使用 -benchmem 还是 ReportAllocs？需要统一观察整组 benchmark 时用 -benchmem；只想控制某个基准的采集范围时用 ReportAllocs。