Go 小对象分配优化对基准测试解读的影响

Go 代码里把临时结构体、短字符串或小切片改成复用对象后，基准测试经常同时出现三个变化：ns/op 下降，B/op 下降，但 allocs/op 可能只下降一点，甚至不变。正确的解读不是“只要小对象更小就一定更快”，而是先固定输入和结果使用方式，再把分配次数、分配字节与 GC 影响分开看。

先分清小对象优化到底改变了什么

一次基准操作可能创建一个临时值，也可能在循环中创建许多短命值。优化方案通常有三种：让值留在栈上、复用已经分配的对象，或改变数据结构以减少中间对象。它们对三个指标的影响不同。

因此，看到 8 B/op 并不等于“业务创建了一个 8 字节对象”，也不能据此推断 GC 一定只处理这 8 个字节。它是 testing 包按一次操作归一化后的统计结果。

用固定输入写出可比较的 benchmark

先避免两个常见干扰：每次迭代临时构造不同输入，以及计算结果没有被使用导致优化器删除工作。下面的示例把输入放到循环外，并把结果写入包级变量，便于比较“直接创建”和“复用缓冲区”两种实现。

package allocbench

import "testing"

var sink []byte

// BenchmarkNewSmallObject 测量每次操作都创建短字节切片的成本。
func BenchmarkNewSmallObject(b *testing.B) {
	for b.Loop() {
		// 让结果逃逸到包级变量，避免整个调用被编译器删除。
		x := make([]byte, 12)
		x[0] = 'G'
		sink = x
	}
}

// BenchmarkReuseSmallObject 测量复用固定容量缓冲区的成本。
func BenchmarkReuseSmallObject(b *testing.B) {
	buf := make([]byte, 12)
	b.ResetTimer()
	for b.Loop() {
		// 只复用当前操作需要的 12 字节，避免把初始化时间算进循环。
		buf[0] = 'G'
		sink = buf
	}
}

这里的 sink 只是让示例的结果保持可观察；真实业务中应把结果传给后续逻辑，不要为了追求零分配而引入共享可变状态。较新的 Go 基准写法可以使用 b.Loop()；如果项目仍采用 for i := 0; i ，也要保持两组基准的循环边界一致。

# 运行同一组基准，并输出 B/op 与 allocs/op。
go test -run '^$' -bench 'Benchmark(New|Reuse)SmallObject$' -benchmem -count=8

# 只查看编译器对当前包的逃逸判断；输出用于解释，不替代基准数据。
go test -run '^$' -gcflags='-m=2' 2>&1 | rg 'make\(\[\]byte|escapes to heap'

命令输出应保存到实验记录中，但不要把一次机器上的绝对数字当成语言保证。先看多次运行的中位趋势，再看离散程度；如果两组结果的差异小于运行抖动，优化结论应暂缓。

从 size class 和 tiny allocator 解释数字

Go 运行时对不超过 32 KB 的小分配按若干 size class 管理。请求大小会被向上取整，分配器优先从当前 P 的 mcache 找对应 span 的空闲槽位；这解释了为什么把结构体从 15 字节改成 17 字节，业务字段只增加 2 字节，B/op 却可能跨到另一个档位。

对于不含指针且小于 tiny 阈值的对象，runtime 还可能把多个请求合并到一个内存块。这个机制主要服务于短字符串和独立逃逸变量，减少的是分配器与堆管理的压力，并不意味着每个 Go 值都获得了可以独立释放的堆块。含指针的对象、需要显式释放语义的对象和超过阈值的对象，都不能简单套用这个解释。

用三组证据确认优化没有骗过基准

第一组证据是基准指标：ns/op、B/op、allocs/op 是否在多次运行中同向改善。第二组证据是逃逸分析：如果本来想优化堆分配，却看到关键临时值仍然 escapes to heap，应先解释逃逸原因。第三组证据是输入与环境：CPU 频率、GOMAXPROCS、GC 周期、缓存状态和输入长度都可能改变结果。

可以按下面的清单判读：

• ns/op 降、allocs/op 降、B/op 降：通常说明对象路径和分配压力都减少，继续用真实流量样本复测。
• ns/op 降但分配指标不变：可能是数据访问、分支或内联改善，不要把收益归因给小对象优化。
• B/op 降但 allocs/op 不变：更像是对象尺寸或容量变小，仍需确认是否跨过 size class 边界。
• 多次运行波动很大：先固定基准进程、输入和运行次数，再考虑 GC 或 CPU 抖动，而不是继续微调字段布局。

最后要保留基线版本和优化版本的源码、Go 版本、命令行参数与原始输出。只有这些条件一致，后续回归才知道“变快”来自代码改动，而不是实验条件改变。

常见问题

为什么小对象数量减少了，allocs/op 却没有归零？

可能还有切片扩容、字符串转换、接口装箱或其他路径分配；tiny allocator 也只合并满足条件的无指针小对象，不能替代逃逸分析。

B/op 比对象大小大很多，是不是基准写错了？

不一定。容量扩张、size class 向上取整、循环内的其他分配以及测试框架归一化都会影响 B/op，应结合最小复现和逃逸输出判断。

优化后 ns/op 只快了 1%，应该保留吗？

先看多次运行的波动和真实请求中的分配占比。如果收益小于噪声，或代码引入了共享状态与可读性成本，通常不值得只为 benchmark 数字保留。