Go语言基准测试如何避免干扰_性能测试注意事项_技术教程

基准测试需用b.ResetTimer()排除初始化耗时，如prepareLargeDataset()等预处理操作；若每次迭代需新数据，则用b.StopTimer()+b.StartTimer()包裹生成逻辑。

计时器没重置，初始化时间全算进去了

基准测试默认从函数入口就开始计时，但像 prepareLargeDataset() 或 make([]byte, 1e6) 这类预处理操作耗时远超被测逻辑本身，结果就变成“测的是内存分配速度”，而不是函数性能。

用 b.ResetTimer() 在准备完成后立即调用，把初始化阶段彻底排除在统计之外
如果每次迭代都需要新数据（比如随机输入），改用 b.StopTimer() + b.StartTimer() 包裹生成逻辑
别在循环外做 defer b.ResetTimer() —— 它不会生效，ResetTimer() 必须显式调用且只影响后续迭代

func BenchmarkProcessData(b *testing.B) {
    data := createTestData() // 耗时操作
    b.ResetTimer()           // ✅ 关键：从此处开始计时
    for i := 0; i < b.N; i++ {
        Process(data)
    }
}

编译器把你的函数优化没了

Go 编译器发现 calculateSum(data) 的返回值没被使用，可能直接删掉整条调用，最终测出来是 0 ns/op —— 不是快，是没跑。

必须把结果赋给一个包级变量（var result int64），或至少是函数外可逃逸的变量
避免用 _ = calculateSum(data)，部分版本仍可能被优化；用 result = calculateSum(data) 更稳妥
如果函数返回结构体或指针，确保字段被读取（比如 result.Field），否则字段级优化仍可能发生

var result int64

func BenchmarkCalculateSum(b *testing.B) {
    data := make([]int, 1000)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        result = calculateSum(data) // ✅ 防止死代码消除
    }
}

GC 和系统负载让数据跳变不止

一次 go test -bench=. 跑出 1200 ns/op，下一次变成 1800 ns/op，不是代码变了，是 GC 恰好在某次迭代中触发，或者后台 Chrome 占了

CPU。

短时低内存测试可用 debug.SetGCPercent(-1) 暂停 GC，但记得 defer debug.SetGCPercent(100) 恢复
加 -benchmem 看 Allocs/op 和 Bytes/op，若这两项偏高，说明 GC 干扰大概率来自你自己的分配，不是环境问题
用 -cpu=1 -count=5 -benchtime=3s 组合：单核运行、5 次重复、每次 3 秒，比默认参数稳定得多
测试前执行 runtime.GC() 强制清理，避免上一轮残留影响

并行测试不加控制，结果完全不可比

b.RunParallel 看似简单，但默认会启动 GOMAXPROCS 个 goroutine，若被测函数访问共享资源（如全局 map、文件句柄），就会出现竞争、锁等待甚至 panic，测出来的不是吞吐量，是调度开销。

并行测试前先确认函数是线程安全的；否则得自己加锁或改用局部状态
用 GOMAXPROCS(1) 或 -cpu=1 先跑单核 baseline，再逐步放开并发数对比
b.RunParallel 内部的 pb.Next() 循环不能包含任何阻塞操作（如 time.Sleep、网络调用），否则会卡住整个并行组

func BenchmarkProcessParallel(b *testing.B) {
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            ProcessOneItem() // ✅ 必须无状态、无共享、无阻塞
        }
    })
}