Go benchmark 怎样报告每次操作的内存分配

如果你只看 ns/op，很容易错过一个实现是否在热路径上持续申请对象。Go benchmark 里最直接的做法，是在目标基准函数中调用 b.ReportAllocs()，再用 go test -bench 读取每次操作的分配次数和字节数。

官方文档：https://pkg.go.dev/testing

把 b.ReportAllocs() 放进要观察的 benchmark 中，就能让该 benchmark 报告 allocs/op 和 B/op。它只影响调用它的 benchmark；准备数据、比较多个实现和并发计数仍然要单独划清边界。

先分清 allocs/op、B/op 和 ns/op

allocs/op 表示每次操作平均发生了多少次分配，适合回答“是不是频繁创建对象”。B/op 表示每次操作平均分配多少字节，适合回答“每次申请的总量有多大”。ns/op 仍然是时间指标，不能代替前两者。

例如一个函数每次只申请一次 4 KB 缓冲区，可能是 1 allocs/op、4096 B/op；另一个函数可能有多次小对象分配。两者都要看，才不会把“次数少但单次很大”和“次数多但单次很小”混为一谈。

在 benchmark 内调用 ReportAllocs

最小写法是让基准函数负责打开分配统计，再把真正要测的操作放入循环。新代码可以优先使用 b.Loop()；需要兼容旧式写法时，也可以继续使用 b.N。

package allocbench

import (
    "bytes"
    "testing"
)

func BenchmarkBuildBuffer(b *testing.B) {
    // 只让这个 benchmark 报告分配统计，不改变其他基准函数。
    b.ReportAllocs()

    for b.Loop() {
        // 被测操作：每次根据固定文本构造一个新的缓冲区。
        var buf bytes.Buffer
        buf.WriteString("request-payload")
        _ = buf.String()
    }
}

运行命令可以把 benchmark 名称、运行次数、耗时和分配指标一起输出：

# -benchmem 让命令行基准统一显示内存分配列；ReportAllocs 仍只作用于目标函数。
go test -run '^$' -bench '^BenchmarkBuildBuffer$' -benchmem ./...

输出中通常会出现 ns/op、B/op 和 allocs/op。文章中的示例输出只用于解释列含义，不代表某台机器上的固定结果；编译器、架构和 Go 版本都会影响实际数值。

把准备阶段移出统计边界

企业代码里经常先准备一份较大的输入，再重复调用被测函数。准备动作如果发生在循环内，确实属于每次操作；如果只是 benchmark 的固定前置数据，就不应该误算成热路径成本。

func BenchmarkParsePayload(b *testing.B) {
    // 固定输入只准备一次，避免把样本构造误当成每次解析。
    input := make([]byte, 4

ResetTimer 会重置已计时的时间和分配计数，因此应在准备阶段结束后使用。要注意它的意义是重设 benchmark 状态，不是自动让循环里的分配消失；被测代码仍然申请内存，就会出现在统计里。

用子 benchmark 比较不同实现

要比较两个实现，最好让输入、统计方式和执行命令保持一致，只把实现名放进子 benchmark。这样结果更容易横向阅读，也不必把多个版本混在一个循环里。

func BenchmarkDecodeVariants(b *testing.B) {
    // 同一份输入服务两个子 benchmark，避免样本差异影响比较。
    input := []byte("name=golang&mode=bench")

    b.Run("split", func(b *testing.B) {
        // 每个子 benchmark 单独开启分配统计，结果归属于当前子项。
        b.ReportAllocs()
        for b.Loop() {
            decodeBySplit(input)
        }
    })

    b.Run("scan", func(b *testing.B) {
        // 保持相同的统计入口，才能比较 allocs/op 和 B/op。
        b.ReportAllocs()
        for b.Loop() {
            decodeByScan(input)
        }
    })
}

实际项目中，比较结果不要只盯着一个数字。若 allocs/op 降了但 B/op 升了，可能是少量大缓冲替代了很多小对象；若两者都降而 ns/op 变慢，则还需要回到算法、拷贝和缓存行为继续判断。

并发 benchmark 里要避免共享计数器

RunParallel 会把 b.N 次迭代分给多个 goroutine。被测对象可以是共享的，但你自己额外记录的计数器必须采用并发安全的方式；否则统计代码本身就会产生数据竞争或错误结果。

func BenchmarkParallelEncode(b *testing.B) {
    var total atomic.Int64

    b.ReportAllocs()
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            // 每个并发迭代产生自己的结果，避免复用同一个可变缓冲区。
            result := encodeItem("go")
            if len(result) > 0 {
                // 跨 goroutine 累加必须使用原子操作，不能直接写普通整数。
                total.Add(int64(len(result)))
            }
        }
    })
}

并发场景下不要在 RunParallel 的回调里调用 ResetTimer、StartTimer 或 StopTimer，因为这些操作对整个 benchmark 有全局影响。ReportAllocs 放在外层，只负责让这项基准带上分配统计；它不会替你修正共享状态。

-benchmem、ReportAllocs 与边界判断

命令行的 -benchmem 是全局开关，适合一次查看多个 benchmark 的分配列；b.ReportAllocs() 是函数级开关，适合只给某个基准开启统计。两者都不会把分配数据变成稳定不变的常数，最终数值仍受输入、编译器、运行环境和实现细节影响。

如果使用旧式 b.N 循环，准备阶段可能在调整 b.N 的多次测量中重复执行；新 benchmark 优先使用 b.Loop()，可以让测试框架更清楚地管理计时边界。迁移时不要同时写 b.Loop() 和手动 b.N 循环。

一份可执行的发布前检查表

• 确认 b.ReportAllocs() 放在目标 benchmark，而不是只放在无关的外层函数。
• 确认固定输入在计时开始前构造，或明确说明它就是被测操作的一部分。
• 确认命令使用了 -benchmem，并按同一输入、同一过滤条件比较结果。
• 确认并发 benchmark 的自定义计数器没有普通共享写入。
• 确认没有把一次机器上的示例数值当成跨环境的性能承诺。

常见问题

为什么加了 ReportAllocs 还是看不到分配列？

先确认运行的是 benchmark 而不是普通测试，并检查命令是否带有 -benchmem。如果通过 go test 过滤了错误的 benchmark 名称，也可能根本没有执行目标函数。

ReportAllocs 会统计 benchmark 函数外的分配吗？

它只影响调用它的 benchmark。准备阶段是否计入，要看计时器何时启动；把固定准备放在循环前，并在旧式 b.N 写法中合理使用 ResetTimer，才能让统计边界与问题一致。

allocs/op 越低就一定越快吗？

不一定。分配次数只是内存行为的一个维度，还要结合 B/op、ns/op、输入规模和并发模型判断。低分配实现也可能因为拷贝更多数据或执行更多计算而变慢。

把 ReportAllocs 当作“打开一组可读指标”的入口即可：先定义被测操作，再划清准备和并发边界，最后在相同条件下同时看 allocs/op、B/op 与 ns/op，这样 benchmark 才能支持真正的实现取舍。