Go benchmark 怎样用报告指标识别分配热点

我排查 Go 性能问题时，最容易误判的一件事，是看到 ns/op 变大就马上去改算法。后来我会先把同一个 benchmark 的 B/op 和 allocs/op 打出来：前者告诉我每次操作分配了多少字节，后者告诉我分配动作发生了多少次。两者同时升高时，才更像是“临时对象太多”这一类分配热点。

这篇只解决一个边界明确的问题：如何用 Go testing 的报告指标发现分配热点，再用 testing.AllocsPerRun 对一个可复现的函数调用做定点测量。示例数字只是输出格式示意，不能当成任何机器上的性能承诺。

先让 benchmark 报出 B/op 和 allocs/op

默认的 benchmark 输出通常只有 ns/op。运行时加上 -benchmem，或者在 benchmark 内调用 b.ReportAllocs()，报告就会增加 B/op 和 allocs/op。下面用两个返回字符串的实现构造对照，重点不在于谁一定更快，而在于如何观察指标。

package render

import (
    "strconv"
    "strings"
    "testing"
)

func renderFormat(id int) string {
    // 该版本用格式化函数拼出结果，便于观察临时字符串的分配情况。
    return "item=" + strconv.Itoa(id)
}

func renderBuilder(id int) string {
    // Builder 把多段文本写入同一个缓冲区，返回前只转换一次结果。
    var b strings.Builder
    b.WriteString("item=")
    b.WriteString(strconv.Itoa(id))
    return b.String()
}

func BenchmarkRender(b *testing.B) {
    // 只让被测调用进入计时区，避免初始化影响报告。
    b.ReportAllocs()
    b.Run("format", func(b *testing.B) {
        for i := 0; i 

在包目录执行：

# -benchmem 让测试框架把内存分配指标一并输出。
go test -run=^$ -bench=BenchmarkRender -benchmem -count=5 ./...

示意输出可以是：

BenchmarkRender/format-8       10000000   118 ns/op   32 B/op   2 allocs/op
BenchmarkRender/builder-8       9000000   132 ns/op   48 B/op   2 allocs/op

三个指标分别说明什么

ns/op 是一次操作的平均耗时，适合发现总体变慢；B/op 是每次操作平均分配的字节数，适合发现对象体积或缓冲区变大；allocs/op 是每次操作平均发生的分配次数，适合发现小对象、临时切片或字符串拼接过于频繁。

判断时我会先看组合，而不是给单个数字下结论：

例如，allocs/op 从 1 变成 3，并不等于一定要优化；如果这段代码不在高频路径，改动可能不值得。反过来，只有一次分配但每次多出几百 KB，也可能比很多小分配更需要优先处理。

用 AllocsPerRun 把范围缩到一个调用

benchmark 报告反映的是整个计时体。若计时体里还包含输入构造、循环和结果处理，就很难知道到底是哪一步产生了分配。这时可以用 testing.AllocsPerRun 测量一个固定调用边界。

package render_test

import (
    "testing"
)

func TestRenderAllocations(t *testing.T) {
    // AllocsPerRun 会先预热一次，再对指定次数求平均分配数。
    avg := testing.AllocsPerRun(100, func() {
        _ = renderFormat(42)
    })

    // 返回值虽然是 float64，但官方语义保证它是整数值。
    if avg > 3 {
        t.Fatalf("分配次数异常：%.0f", avg)
    }
}

这个函数有两个容易忽略的边界。第一，测量前会额外运行一次被测函数作为预热，所以不要把第一次调用当成统计样本。第二，测量期间会把 runtime.GOMAXPROCS 临时设为 1，返回前再恢复；它适合做稳定的单调用分配计数，不等同于并发吞吐测试。

怎样避免把一次偶然波动当成热点

确认方向时，我会保持输入、编译参数和 benchmark 名称不变，用 -count=5 重复采样，再比较同一环境下的改动前后。只看到一行输出，不足以证明某个优化有效；机器负载、CPU 频率、垃圾回收和输入分布都可能影响 ns/op。

如果分配指标确实异常，可以继续用 go test -gcflags=-m=2 查看编译器的逃逸提示，或者单独收集内存剖析来观察更大的调用关系。这里的顺序很重要：benchmark 报告先告诉你“有没有分配现象”，定点测量再告诉你“哪一段值得继续看”，不要把任何一个指标直接当作优化结论。

一句话总结：用 ns/op 看总体耗时，用 B/op 看每次分配了多少字节，用 allocs/op 看分配发生了多少次；需要缩小范围时，再用 AllocsPerRun 测一个明确的调用边界。

相关问题

为什么只看 allocs/op 不够？

因为它只表示次数，不表示每次分配的大小。一次大缓冲区分配可能让 B/op 明显升高，但 allocs/op 仍然接近 1。

ReportAllocs 和 -benchmem 选哪个？

-benchmem 适合统一打开一组 benchmark 的内存指标；ReportAllocs 只影响调用它的 benchmark，适合把关注范围写进测试代码。

官方参考地址：https://pkg.go.dev/testing