17370845950

Go基准测试必须用go test -bench启动，手动运行无效；函数需为func BenchmarkXxx(*testing.B)格式；b.ResetTimer()应在初始化后、循环前调用，避免准备时间计入耗时。

Go benchmark test 必须用 go test -bench 启动

直接运行 go run 或手动调用 BenchmarkXXX 函数不会触发基准测试框架的计时、迭代和结果统计逻辑，测出的数字毫无意义。Go 的 testing.B 对象在 -bench 模式下才自动控制循环次数、预热、采样和内存分配统计。

常见错误包括：

• 在普通 main 函数里调用 time.Now() 手动测耗时 —— 忽略 GC 干扰、CPU 频率波动、编译器优化干扰
• 忘记加 -benchmem，导致看不到 Allocs/op 和 B/op，漏掉内存分配瓶颈
• 用 -bench=. 匹配所有函数，但没加 -run=^$ 排除单元测试，导致 benchmark 被中断或污染

正确启动方式示例：

go test -bench=BenchmarkParseJSON -benchmem -run=^$

Benchmark 函数签名不能省略 *testing.B 参数

Go 要求基准函数必须是 func BenchmarkXxx(*testing.B) 形式，且函数名以 Benchmark 开头、首字母大写。否则 go test -bench 会直接忽略。

容易被忽略的关键点：

• b.ResetTimer() 应在初始化代码（如构造输入数据）之后、实际压测循环之前调用，否则把准备时间也算进耗时
• b.ReportAllocs() 可显式开启内存统计（-benchmem 已默认启用，但某些 CI 环境可能关闭）
• 不要在循环内调用 b.StopTimer() / b.StartTimer() 来“排除某段代码”——这会让迭代次数失真；应把非目标逻辑移到循环外

典型结构示例：

func BenchmarkParseJSON(b *testing.B) {
    data := loadSampleJSON() // 预加载，不计入耗时
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = json.Unmarshal(data, &struct{}{})
    }
}

避免编译器优化导致 Benchmark 结果为 0 ns/op

如果被测函数返回值未被使用，且 Go 编译器判定该调用无副作用，整个调用可能被完全优化掉，最终显示 0 ns/op —— 这不是性能好，是没跑。

解决方法只有两个：

• 用 blackhole 方式强制保留结果：将返回值赋给全局变量 var result = ...，或调用 runtime.KeepAlive()
• 更推荐的是：用 testify/assert 或原生 if 做轻量断言（例如 if len(out) == 0 { b.Fatal("empty") }），既防优化又验证逻辑正确性

反模式示例（会被优化）：

for i := 0; i < b.N; i++ {
    json.Unmarshal(data, &v) // v 未被读取，整行可能消失
}

修复后：

var blackhole interface{}
for i := 0; i < b.N; i++ {
    err := json.Unmarshal(data, &v)
    if err != nil {
        b.Fatal(err)
    }
    blackhole = v // 强制保留 v 的使用
}

对比多个实现时，用 -benchmem + -count=5 看稳定性

单次 benchmark 结果波动大，尤其涉及内存分配或系统调用时。仅看一次 ns/op 容易误判。真正有参考价值的是多次运行后的中位数与标准差。

建议组合参数：

• -benchmem：固定开启内存指标，避免遗漏 Allocs/op 高但 ns/op 低的“伪快”实现
• -count=5：运行 5 轮，go test 会自动输出每轮结果及汇总统计
• -benchtime=5s：延长单轮运行时间（默认 1s），减少启动/预热噪声占比

注意：不同实现的 b.N 可能不同（benchmark 框架自动调整迭代次数以满足 -benchtime），所以必须比 ns/op，而不是总耗时或 b.N 值。

真实瓶颈常藏在 Allocs/op 里，比如一个函数快 20%，但 Allocs/op 高 10 倍 —— 在高频服务中反而更容易触发 GC 停顿。别只盯着 ns/op 看。