Go Benchmark 测量分配次数的基准设计

Go Benchmark测量分配次数时，先定义一次操作包含什么，再在夹具初始化后调用ResetTimer，并用ReportAllocs打开分配统计。把不同输入规模拆成子基准，保持结果生命周期一致，才能比较allocs/op；仅仅加上-benchmem并不能修正一个把造数据、日志和业务处理混在一起的基准。

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

把问题缩成一次完整的字节拼接

假设服务里有一段代码，把多段字节拼成一个新切片。可选择从空切片持续append，也可以先计算总长度再预分配。要回答“哪种设计减少分配”，先约定一次操作是拼接整批输入，而不是只追加一段，也不是复用上轮已经扩大的输出缓冲区。

下面的原创最小配方把两种实现放到相同的测试框架：输入每段固定32字节，段数分别为8、128、2048。它们是教学用规模，不代表生产流量分布。本文只设计基准，不运行测试、不提供虚构分配数字，也不据此宣布某实现更快。

可直接放进_test.go的最小配方

在独立示例目录的Go模块中，将代码保存为join_test.go。这里沿用b.N循环，便于明确讨论ResetTimer的边界；不要在同一测量循环中混用b.N与另一套循环控制方式。

package allocdemo

import (
    "fmt"
    "testing"
)

// 保留每次返回的切片；本例测量“结果可被调用者持有”的分配口径。
var resultSink []byte

func joinChunks(chunks [][]byte, reserve bool) []byte {
    var out []byte
    if reserve {
        total := 0
        for _, chunk := range chunks {
            total += len(chunk)
        }
        out = make([]byte, 0, total)
    }
    for _, chunk := range chunks {
        out = append(out, chunk...)
    }
    return out
}

func benchmarkJoin(b *testing.B, reserve bool) {
    b.Helper()
    for _, count := range []int{8, 128, 2048} {
        count := count
        b.Run(fmt.Sprintf("chunks=%d", count), func(b *testing.B) {
            // 固定夹具只创建一次，不纳入“拼接一次”的计量范围。
            chunks := make([][]byte, count)
            for i := range chunks {
                chunks[i] = make([]byte, 32)
                for j := range chunks[i] {
                    chunks[i][j] = byte((i + j) % 251)
                }
            }
            b.ReportAllocs()
            b.ResetTimer()
            for i := 0; i 

本例将结果放到包级resultSink，表达返回切片可以在调用之后继续存活。两种实现都采用相同的结果消费方式，因此不会一边让结果逃逸、另一边立即丢弃。这个选择本身也属于测试契约：如果真实场景在函数内部立即消费结果，基准应另行设计，不能强行把这里的分配数当成所有调用方式的事实。

ResetTimer与ReportAllocs分别解决什么

ReportAllocs启用该基准的内存分配统计；ResetTimer把此前累计的时间与分配计数清零。因此，chunks的构造放在ResetTimer之前，joinChunks内部为返回结果申请空间则留在循环内。否则，测到的数字可能回答的是“造一份输入再拼接要多少分配”，而不是本文约定的“已有输入拼接一次”。

ResetTimer不会自动排除以后发生的操作，也不会改变计时器当前是否运行。循环里新建输入、格式化日志或保存整批历史结果，仍会改变测量口径。它还会清除用户报告的自定义指标，所以自行添加ReportMetric时应安排好位置，不要报告后又重置。

不要为了把allocs/op降下来，把本来每次必须执行的业务准备工作全部挪到循环外。本例允许复用只读输入，但每次必须生成新输出，预分配实现中的总长度计算和make仍然都在计量范围内。这才是同一项任务的比较，而不是把一种实现的成本藏起来。

输入规模改变的是一次操作的工作量

子基准名字中的chunks=128说明一次调用消费128段，每段32字节。allocs/op中的op就是这一次整批调用，不是一个字节或一条输入。如果另一份基准把每一段算成一次op，两个结果不能直接横向比较。

仅看分配次数也不够。allocs/op反映平均每次操作的分配计数，B/op反映平均每次操作累计分配的字节量，ns/op反映耗时。少一次分配不等于更少内存驻留，分配字节数也不等于当前存活堆大小或进程峰值内存。扩大规模后，除了次数，还要注意输出大小和扩容所产生的累计分配。

固定规模适合形成易对比的样本，但实际输入可能长短不一、包含空段或偶发大段。可以新增这些独立案例，保持同一案例在两个实现中使用同一份输入分布；不要在被测循环里随机生成数据，却又把随机数和分配成本算成拼接成本。

运行命令与结果阅读方式

下列命令供读者在自己的示例模块中执行。这里只给方法，不附带伪造输出，也不承诺固定的allocs/op值。

# 在包含join_test.go的示例模块目录执行，跳过普通测试并重复基准
go test -run='^$' -bench='^BenchmarkJoin' -benchmem -count=5

-benchmem让命令所选基准输出内存统计；代码中的ReportAllocs也会对调用它的基准启用统计。二者同时存在不会把实际分配翻倍。-count=5用于观察多次结果，不意味着五次取平均后就自动消除了机器负载、工具链或运行环境差异。

比较时保留完整子基准名，并记录Go工具链、目标架构、相关编译设置和运行环境。b.N由基准框架调整以取得合适的测量长度，不应硬编码成输入规模，也不要让函数行为依赖b.N改变数据量。示例中每一轮始终拼接相同数量的段。

变体要明确改变的是哪个契约

最常见的误差来自循环外复用输出：第一轮扩容以后，后续轮次使用已有容量，测到的是热缓冲区场景。这可以是合理实验，但必须独立命名，不能用它去证明“每次新建结果零分配”。同样，包级sink会保留最近一次结果，但并不保留所有历史输出；改成把每次结果都append到一个大集合，会引入额外存储语义。

本例没有并行基准，因此共享sink按顺序写入。若扩展为RunParallel，不能直接让多个goroutine同时写同一slice变量；那已经是另一套并发测试设计。也不要用关闭优化、修改编译参数等方式只改善一边的数字，然后和另一边正常构建的结果比较。

常见补充问题

0 allocs/op是否说明函数完全没有内存成本？

不是。它只是当前测量契约与工具链下报告的分配指标，不包含所有栈空间、已有缓冲区容量、存活对象或进程内存成本，也不能代表所有输入。

为什么ResetTimer前的输入仍会影响结果？

统计计数被清零不等于程序状态被恢复为不存在。输入对象仍然存活，缓存和运行时状态也仍然存在，所以它排除的是计量成本，不是把环境变成理想真空。

基准能代替正确性测试吗？

不能。先通过独立测试确认两个实现产生相同字节内容，再把性能数字用于比较。本文不执行这些测试，也不把尚未测量的优化方向写成已证实收益。

一个可信的分配基准先把op、输入和结果生命周期说清，再讨论数字。ResetTimer负责清除前期计数，ReportAllocs负责展示统计，分规模子基准负责让结果对应具体工作量；三者都不能替代这个设计前提。