17370845950

Go基准测试需确保条件一致：相同Go版本、构建参数、禁用CPU频率缩放、-benchmem统计内存、-count=5取中位数；Benchmark函数须防优化干扰、固定输入、正确使用b.ResetTimer和//go:noinline；用benchstat比对并关注p值与geomean提升。

用 go test -bench 跑出可比的基准测试结果

Go 自带的 testing.B 是做性能对比最直接、最可信的方式。关键不是“跑一次”，而是让优化前后的测试在相同条件下运行，否则数字毫无意义。

• 必须用 -benchmem 同时开启内存分配统计，避免只看耗时忽略 GC 压力
• 禁用 CPU 频率缩放（Linux 下执行 sudo cpupower frequency-set -g performance），否则 BenchmarkFoo-8 的结果波动可能达 ±20%
• 确保两次测试使用完全相同的 Go 版本和构建参数（如 GOOS=linux GOARCH=amd64 go test），跨平台或跨版本对比无效
• 单次运行不足以定论，建议用 -count=5 取中位数，例如：go test -bench=^BenchmarkParse$ -benchmem -count=5

写可复现的 Benchmark 函数要注意什么

很多初学者写的 benchmark 看似在测逻辑，实则测的是编译器优化或空循环——比如忘记调用 b.ReportAllocs() 或误用 b.N。

• b.ResetTimer() 必须放在初始化代码之后、主循环之前，否则把 setup 时间也算进耗时
• 被测函数不能是内联候选（加 //go:noinline 注释），否则优化前后可能走不同路径
• 输入数据要固定（如从字节切片预生成，而非每次 fmt.Sprintf），否则引入非目标变量
• 避免在循环里做非目标操作：比如测 JSON 解析，就别在 for i := 0; i 里重复 json.Unmarshal 以外的 map 构造或日志打印

func BenchmarkParseJSON(b *testing.B) {
	data := []byte(`{"name":"alice","age":30}`)
	b.ResetTimer()
	for i := 0; i < b.N; i++ {
		var u User
		json.Unmarshal(data, &u) // ← 这才是唯一被测行为
	}
}

对比两版实现时，benchstat 比肉眼更可靠

直接看 12.42 ns/op → 9.11 ns/op 容易误判——得确认是否显著。Go 官方工具链提供了 benchstat（需 go install golang.org/x/perf/cmd/benchstat@latest）。

• 分别保存两组结果：go test -bench=Parse -count=10 > old.txt 和 > new.txt
• 执行 benchstat old.txt new.txt，它会自动做 t-test 并标出 p 值和提升百分比
• 输出中若出现 geomean: 1.37x faster 且 p=0.0002，才算可信提升；若写 0.98x (±2.1%) 就基本没变
• 注意：如果 old.txt 和 new.txt 的 BenchmarkXXX-8 后缀不一致（比如一个跑在 8 核、一个跑在 4 核），benchstat 会拒绝比较

容易被忽略的干扰项：GC、调度、缓存行伪共享

哪怕 benchmark 写对了，真实性能差异也可能被底层机制掩盖。

立即学习“go语言免费学习笔记（深入）”；

• 高频率小对象分配（如每轮新建 map[string]int）会让 gc pause 成为主因，此时看 B/op 比 ns/op 更关键
• 并发 benchmark（如 runtime.GOMAXPROCS(1) 未锁定）可能因 goroutine 抢占导致抖动，建议显式设置 runtime.GOMAXPROCS(1) 再测单核场景
• 结构体字段顺序不当会导致多个 hot field 落在同一 cache line，引发伪共享；用 unsafe.Offsetof 检查字段布局，必要时手动填充对齐
• 如果优化后 ns/op 变差但 B/op 大幅下降，说明你用空间换时间成功了——这在内存受限服务里反而是正向收益

实际压测时，ns/op 数字稳定只是起点；真正要盯住的是 allocs/op 是否增长、GC 频次是否上升、以及在线上流量下 P99 延迟是否同步改善。