Go BenchmarkAllocsPerRun 数值变化大时先检查什么

如果 testing.AllocsPerRun 读出来的数字一会儿是 1、一会儿是 2，先不要急着把它归因于垃圾回收。最应该检查的是被测闭包是否把初始化、缓存建立或可变输入带进了统计，以及测试是否和其他 goroutine 共享了运行环境。这个函数会先执行一次 warm-up，再统计后续调用的分配差值；返回值虽然是 float64，实际通过整数除法得到，因此它更适合做稳定的分配预算断言，而不是替代完整性能基准。

排查顺序可以固定为：先移出一次性初始化，再保证每轮输入和状态一致，接着确认测试没有并行或后台分配，最后才增加 runs 或改用 benchmark。数字仍变化时，优先看测量边界，而不是只看结果大小。

先确认 AllocsPerRun 究竟统计哪一段

源码里的边界很明确：函数先调用一次 f 作为预热，然后读取内存统计；接着调用 f 指定的次数，再读取统计并用总分配次数除以 runs。预热本身不进入平均值，但预热可能改变闭包捕获的对象、切片容量、包级缓存或连接池状态，所以“第一次慢”与“每次都多分配”不是同一件事。

另一个容易忽略的事实是，测量期间 GOMAXPROCS 会暂时变成 1，返回前恢复原值。这能减少调度差异，却不能让后台 goroutine 消失；被测函数若启动 goroutine，或测试进程中还有共享任务在分配，前后 runtime.MemStats 的差值仍可能被干扰。

把初始化和每轮状态拆开检查

最常见的波动来自闭包里混着两种工作：第一次调用要建立缓存或扩容，之后调用只处理稳定数据。先把输入构造、容量准备和一次性对象放到闭包外，再让闭包只完成目标操作。示例中的全局 sink 用来保留结果，避免编译器把没有消费的结果优化掉：

var allocSink []byte

func TestCopyAllocBudget(t *testing.T) {
    input := bytes.Repeat([]byte("go"), 512)
    allocSink = make([]byte, 0, len(input))

    allocs := testing.AllocsPerRun(1000, func() {
        // 复用容量，把测量范围限定为复制动作。
        allocSink = append(allocSink[:0], input...)
    })
    if allocs != 0 {
        t.Fatalf("copy allocs = %v, want 0", allocs)
    }
}

这个断言的重点不是追求“永远为 0”，而是先定义预算：输入准备不算，复制动作也不应因为容量不足而临时扩容。如果被测逻辑本来就要创建对象，可以把预算写成 1 或 2，但不要把一次性建表、随机数种子、文件读取放进闭包再拿数字比较。

复测时逐项改动并记录原因，通常比盲目把 runs 从 100 增到 10000 更快：

用串行复测排除环境噪声

AllocsPerRun 不能在并行测试中使用；官方实现检测到并行测试状态会 panic。即使没有显式调用 t.Parallel，闭包启动的 goroutine、定时器回调或包级后台任务也会让内存统计不再只属于当前动作。排查时先让该测试独立运行，关闭不必要的后台任务，不要让多个用例共享会增长的 slice、map 或缓存。

样本数也要和目标匹配。若每次操作平均分配 1 次，100 次样本已经能看到大致预算；若目标是区分 0.02 和 0.03 这类稀疏事件，AllocsPerRun 的整数平均会把它们都压到 0，继续加大 runs 只能提高观察机会，不能改变函数返回整数平均值这一语义。此时应记录更长窗口，或改用 benchmark 的 allocs/op 结果做统计比较。

分配预算与性能基准要分工

可以把判断分成两条线：单元测试里用 AllocsPerRun 约束一个动作最多分配几次；性能测试里用 testing.B 测量可重复的操作吞吐和耗时。benchmark 的初始化应放在循环外，只有目标操作进入计时区域；多个版本或提交的结果再用 benchstat 进行统计比较。这样“分配次数变了”和“整体变慢了”不会互相替代。

func BenchmarkEncode(b *testing.B) {
    payload := bytes.Repeat([]byte("go"), 512)
    b.ReportAllocs()

    for b.Loop() {
        // 每轮只测编码动作，避免把样例准备时间算进去。
        allocSink = append(allocSink[:0], payload...)
    }
}

最后可用这张清单收口：闭包内是否只有目标动作；输入是否固定；可变缓冲区是否预分配；测试是否串行；是否同时关心 ns/op；结果是否来自多次独立运行。前四项解决测量边界，后两项解决指标选择和统计可信度。

常见问题

为什么 AllocsPerRun 返回 float64 却看起来总是整数？

这是 API 签名的结果。实现先用整数除法计算平均分配次数，再转换成 float64 返回，所以不要用小数精度来推断稀疏分配。

把 GOMAXPROCS 设为 1 后还会有波动吗？

会。它只限制测量时的处理器并行度，并不替你停止后台 goroutine、外部进程或共享内存活动；先隔离测试环境。

什么时候不该用 AllocsPerRun？

当问题是吞吐、延迟、CPU 消耗或两个提交的整体差异时，不要只看它。使用 benchmark 产生 ns/op、B/op、allocs/op，再做多次结果比较。

参考资料：Go testing 包文档、Go 官方 AllocsPerRun 源码。