17370845950

Go基准测试必须用go test -bench触发，函数名以Benchmark开头、参数为*testing.B、文件名含_test.go；b.ResetTimer()重置计时和b.N，b.StopTimer()/StartTimer()控制计时区间。

如何用 go test -bench 正确触发基准测试

Go 的基准测试不是靠手动调用函数，而是必须通过 go test -bench 命令自动发现并执行，且函数签名严格限定为 func BenchmarkXxx(*testing.B)。名字不以 Benchmark 开头、参数类型不对、或放在非 _test.go 文件里，都会被完全忽略。

• 文件名必须是 xxx_test.go（不能是 benchmark.go 或 perf.go）
• 函数必须接收 *testing.B 参数，不能是 *testing.T 或其他类型
• 默认只运行 Benchmark.*，想跑特定函数就写 go test -bench=^BenchmarkMyFunc$
• 加 -benchmem 才会显示内存分配统计，否则 b.AllocsPerOp() 和 b.N 无关的内存数据不会输出

b.ResetTimer() 和 b.StopTimer() 的真实用途

它们不是“暂停计时器”这种字面意思，而是控制「计入最终耗时的代码段」——只有在 timer running 状态下执行的代码，才参与 b.N 次循环的平均耗时计算。初始化、预热、结果验证等辅助逻辑应排除在外。

• b.StopTimer()：停掉计时，可用于 setup 或 cleanup 阶段，比如构建大输入、解析 JSON、初始化 map
• b.StartTimer()：重新开启（不是“继续”，而是新启一个计时窗口）
• b.ResetTimer()：清空已累计耗时 + 重置 b.N 计数器，常用于跳过冷启动抖动（比如首次 GC、cache miss），但要小心：它会让前序所有循环失效，只从 reset 后开始统计

func BenchmarkJSONUnmarshal(b *testing.B) {
    data := []byte(`{"name":"foo","age":42}`)
    var u struct{ Name string; Age int }

    b.ResetTimer() // 跳过变量声明和 data 构造的开销
    for i := 0; i < b.N; i++ {
        json.Unmarshal(data, &u) // 这段才被计时
    }
}

为什么 b.N 不是固定次数，而要由 Go 自动调整

b.N 是 Go 根据目标耗时（默认 1 秒）动态确定的迭代次数，不是你指定的循环上限。它会先试跑少量次数（如 1、10、100），估算单次耗时，再放大到接近 1 秒的总耗时。这意味着：

• 同一函数在不同机器、不同负载下 b.N 可能差几倍，不能硬编码依赖它的值
• 如果函数本身极快（纳秒级），b.N 可能达到百万甚至千万级，此时要注意整数溢出、内存缓存效应干扰
• 若函数含阻塞操作（如 time.Sleep、网络请求），Go 可能因超时直接中止，报错 too many iterations，这时得用 b.SetBytes() 或手动控制循环
• 避免在循环体内做条件判断或分支跳转，尤其是基于 i % 100 == 0 这类逻辑——它会污染 CPU 分支预测，让结果失真

对比多个实现时，如何避免编译器优化干扰

Go 编译器会对未使用的返回值、无副作用的变量赋值做删除（dead code elimination）。如果你只测函数执行，但没用到返回值，整个调用可能被优化掉，导致基准结果为 0 ns/op。

• 强制保留结果：用 blackhole := fn(...) + blackhole 在循环外引用（但别放循环内，否则增加额外开销）
• 更可靠方式：用 testing.Benchmark 返回值捕获，或直接调用 runtime.KeepAlive()
• 禁用优化仅用于调试：go test -gcflags="-l -N" -bench=.，但生产对比务必用默认编译选项
• 对 slice/map 操作要特别注意：append 可能触发底层数组扩容，导致某次迭代突然变慢，建议预先 make([]T, 0, cap) 固定容量

func BenchmarkMapLookup(b *testing.B) {
    m := make(map[string]int)
    for i := 0; i < 1000; i++ {
        m[fmt.Sprintf("key-%d", i)] = i
    }
    keys := make([]string, 0, 1000)
    for k := range m {
        keys = append(keys, k)
    }

    b.ResetTimer()
    var blackhole int
    for i := 0; i < b.N; i++ {
        blackhole = m[keys[i%len(keys)]] // 强制使用结果
    }
    runtime.KeepAlive(blackhole) // 防止编译器认为 blackhole 无用
}

实际写基准时，最容易漏掉的是 b.ResetTimer() 的位置和 runtime.KeepAlive() 的配对——前者导致 setup 时间混入测量，后者让整个循环被优化成空操作。这两处一错，数据就完全不可信。