Go 基准测试精度指南：结合 100 Go Mistakes 源码剖析如何写出准确可复现的 Benchmark

• 示例工程

在 Go 中做性能优化时，我们往往凭直觉猜测热点，但正如《100 Go Mistakes and How to Avoid Them》第 89 节所指出的：永远不要凭空猜测性能，而要写基准测试去验证。然而，写基准测试本身并不简单，很容易写出"看似严谨、实则失真"的代码，并基于错误假设做出错误决策。本文以 docs/89-benchmarks.md 为主体，结合本仓库 src/11-testing/89-benchmark 下的完整可运行源码与测试，系统讲解 Go 基准测试的运行机制，并逐一剖析导致结果失真的四大陷阱：不重置/暂停计时器、微基准测试的错误假设、被编译器优化欺骗、以及观察者效应。读完本文，你将掌握一套可复制、可验证的 Benchmark 编写范式，避免得出误导性的性能结论。

Go 基准测试基础：Benchmark 骨架与 b.N 机制

先回顾 Go 基准测试的基本运行方式。一个基准测试函数的标准骨架如下：

func BenchmarkFoo(b *testing.B) { for i := 0; i < b.N; i++ { foo() } }

关键点有三个：

1. 命名前缀：函数名必须以Benchmark开头，go test才能识别并执行它。
2. b.N是动态迭代次数：b.N不是一个固定值。运行基准测试时，Go 会尽量让测试耗时匹配"期望的基准时间"（默认 1 秒），可通过-benchtime标志调整。b.N从 1 开始；如果在 1 秒内跑完，b.N会增大并重新运行，直到b.N大致匹配benchtime。
3. 被测函数在循环体内被反复调用：循环之外只做一次性初始化，循环之内才是被测代码的真实耗时区间。

一个典型输出如下：

$ go test -bench=. cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkFoo-4 73 16511228 ns/op

-4表示使用了 4 个 CPU 核心（GOMAXPROCS），73是迭代次数，16511228 ns/op是单次操作的平均耗时。如果改用-benchtime=2s，迭代次数会翻倍、单次耗时基本稳定：

$ go test -bench=. -benchtime=2s BenchmarkFoo-4 150 15832169 ns/op

理解了这套基础机制，接下来逐个击破四大常见陷阱。

陷阱一：不重置或暂停计时器

一次性昂贵初始化：用ResetTimer

有时我们需要在进入循环前执行耗时的初始化（例如生成一个很大的数据切片），这些时间会被算进基准结果，导致结果被严重污染：

func BenchmarkFoo(b *testing.B) { expensiveSetup() for i := 0; i < b.N; i++ { functionUnderTest() } }

解决办法是在进入循环前调用b.ResetTimer()：

func BenchmarkFoo(b *testing.B) { expensiveSetup() b.ResetTimer() // Reset the benchmark timer for i := 0; i < b.N; i++ { functionUnderTest() } }

ResetTimer会把"自测试开始以来的累计运行时间和内存分配计数"清零，从而把昂贵的一次性初始化从测试结果中剔除。仓库中的 timer/main_test.go 正是这一模式的示例：expensiveSetup()在循环外执行，随后b.ResetTimer()再进入循环。

每次迭代都有昂贵操作：用StopTimer/StartTimer

如果昂贵初始化不是只做一次，而是每个循环迭代都要执行，就不能再用ResetTimer（它只能在循环外调用一次）。此时应暂停和恢复计时器，把初始化操作"包"在计时区间之外：

func BenchmarkFoo(b *testing.B) { for i := 0; i < b.N; i++ { b.StopTimer() // Pause the benchmark timer expensiveSetup() b.StartTimer() // Resume the benchmark timer functionUnderTest() } }

b.StopTimer()暂停计时，完成 setup 后b.StartTimer()恢复计时，于是只有functionUnderTest()的执行时间被计入。对应实现同样位于 timer/main_test.go。

注意一个隐藏陷阱：如果被测函数相对于 setup 函数执行得太快，这种写法会让整个基准测试耗时远超预期——因为benchtime的计算只基于functionUnderTest的执行时间，每次循环里等待 setup 的时间并不会被算进"1 秒目标"里。结果是跑完整个 benchmark 可能需要远超过 1 秒。如果坚持保留这种写法，一个可行的缓解措施是调小-benchtime。

要保证基准测试的精度，计时器方法（ResetTimer、StopTimer、StartTimer）必须按场景正确使用。

陷阱二：微基准测试的错误假设

微基准测试（micro-benchmark）度量的是极小的计算单元，其结论极易被外部因素带偏。书中的经典例子：我们拿不准该用atomic.StoreInt32还是atomic.StoreInt64（假设值总是能装进 32 位），于是分别写两个 benchmark：

func BenchmarkAtomicStoreInt32(b *testing.B) { var v int32 for i := 0; i < b.N; i++ { atomic.StoreInt32(&v, 1) } } func BenchmarkAtomicStoreInt64(b *testing.B) { var v int64 for i := 0; i < b.N; i++ { atomic.StoreInt64(&v, 1) } }

这段代码在仓库中有完整实现：wrong-assumptions/main_test.go。

第一次运行，输出可能如下：

cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkAtomicStoreInt32 BenchmarkAtomicStoreInt32-4 197107742 5.682 ns/op BenchmarkAtomicStoreInt64 BenchmarkAtomicStoreInt64-4 213917528 5.134 ns/op

看起来atomic.StoreInt64更快（5.134 ns vs 5.682 ns），我们很可能就此拍板选StoreInt64。然而，仅仅交换两个 benchmark 的书写顺序，结果就反转了：

BenchmarkAtomicStoreInt64 BenchmarkAtomicStoreInt64-4 224900722 5.434 ns/op BenchmarkAtomicStoreInt32 BenchmarkAtomicStoreInt32-4 230253900 5.159 ns/op

这次是atomic.StoreInt32更快。为什么会这样？微基准测试受大量因素影响：运行时的机器负载、电源管理、热降频（thermal scaling）、指令序列的缓存对齐等。很多因素甚至完全超出 Go 项目的范围。

缓解手段

• 保证机器空闲：执行基准测试的机器应当空闲。但后台外部进程仍可能干扰结果，因此社区有perflock之类的工具来限制基准测试可消耗的 CPU 比例。例如把基准测试限制在总 CPU 的 70%，留 30% 给 OS 和其他进程，从而减弱机器活动因素的干扰。
• 调大-benchtime：类似概率论中的大数定律，当运行次数足够多时，结果会趋近期望值（前提是不考虑指令缓存等机制的收益）。
• 用benchstat做统计分析：benchstat是golang.org/x仓库中的工具，可以计算并比较多次基准执行的统计量。先运行 10 次并把输出落到文件：

$ go test -bench=. -count=10 | tee stats.txt cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkAtomicStoreInt32-4 234935682 5.124 ns/op BenchmarkAtomicStoreInt32-4 235307204 5.112 ns/op // ... BenchmarkAtomicStoreInt64-4 235548591 5.107 ns/op BenchmarkAtomicStoreInt64-4 235210292 5.090 ns/op // ...

再用benchstat分析：

$ benchstat stats.txt name time/op AtomicStoreInt32-4 5.10ns ± 1% AtomicStoreInt64-4 5.10ns ± 1%

结论变得清晰：两个函数的平均耗时都是 5.10 纳秒，且 ±1% 的波动说明两者都很稳定。于是正确结论不是"哪个更快"，而是"在我们测试的用法下（特定 Go 版本、特定机器上），两者耗时相当"。

另外要提醒：在一台机器上的微基准结果，不能想当然移植到另一台机器。生产环境的硬件与基准机可能表现差异巨大。

陷阱三：被编译器优化欺骗

另一个常见错误是没有意识到编译器优化会悄悄"优化掉"被测代码，导致基准结果虚低。书中以著名的 Go issue #14813（Go 项目成员 Dave Cheney 曾参与讨论）中的 population count（统计二进制中置 1 的位数）函数为例：

const m1 = 0x5555555555555555 const m2 = 0x3333333333333333 const m4 = 0x0f0f0f0f0f0f0f0f const h01 = 0x0101010101010101 func popcnt(x uint64) uint64 { x -= (x >> 1) & m1 x = (x & m2) + ((x >> 2) & m2) x = (x + (x >> 4)) & m4 return (x * h01) >> 56 }

这段实现原样保存在 compiler-optimizations/main.go。直接写基准测试：

func BenchmarkPopcnt1(b *testing.B) { for i := 0; i < b.N; i++ { popcnt(uint64(i)) } }

运行结果低得离谱：

cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkPopcnt1-4 1000000000 0.2858 ns/op

0.28 纳秒大约就是一个时钟周期，这个数字不合理。原因在于：popcnt足够简单，成了内联（inlining）的候选——编译器用函数体替换函数调用，省去调用开销。函数被内联后，编译器发现该调用没有任何副作用，于是直接把循环体替换为空：

func BenchmarkPopcnt1(b *testing.B) { for i := 0; i < b.N; i++ { // Empty } }

基准测试被"优化"成了空循环，结果自然接近一个时钟周期。仓库对应代码在 compiler-optimizations/main_test.go。

最佳实践：局部变量 + 全局变量模式

防止编译器优化吞噬被测代码的标准做法分两步：

1. 每个循环迭代中，把函数返回值赋给一个局部变量（作用域限定在基准函数内）；
2. 循环结束后，把最后一次结果赋给一个全局变量。

var global uint64 // Define a global variable func BenchmarkPopcnt2(b *testing.B) { var v uint64 // Define a local variable for i := 0; i < b.N; i++ { v = popcnt(uint64(i)) // Assign the result to the local variable } global = v // Assign the result to the global variable }

global是全局变量，v是基准函数内的局部变量。每次迭代把结果写入局部变量，最后再把最新结果写入全局变量。这样既让编译器看到结果"被使用"而无法删掉调用，又避免了不必要的开销。对应实现见 compiler-optimizations/main_test.go。

为什么不直接把结果写进global简化代码？写全局变量比写局部变量慢（涉及栈与堆的分配差异，参见本书 mistake #95 "Not understanding stack vs. heap"）。因此在每次迭代中应写入局部变量以压低开销，只在循环结束后写一次全局变量。

对比两个 benchmark 的结果：

cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkPopcnt1-4 1000000000 0.2858 ns/op BenchmarkPopcnt2-4 606402058 1.993 ns/op

BenchmarkPopcnt2才是准确版本：它规避了内联优化导致的耗时虚低甚至调用被整体删除。如果当初轻信BenchmarkPopcnt1，就会得出完全错误的性能结论。

陷阱四：被观察者效应愚弄

物理中的观察者效应指"观察行为本身干扰了被观察系统"。基准测试同样存在这种效应——反复观察同一个被测函数，会因 CPU 缓存等底层机制显著扭曲结果。

场景：512 列 vs 513 列的求和

假设要实现一个函数：输入是固定 512 列的int64矩阵，计算前八列的总和；为了研究列数是否影响性能，再实现一个 513 列版本：

func calculateSum512(s [][512]int64) int64 { var sum int64 for i := 0; i < len(s); i++ { // Iterate over each row for j := 0; j < 8; j++ { // Iterate over the first eight columns sum += s[i][j] // Increment sum } } return sum } func calculateSum513(s [][513]int64) int64 { // Same implementation as calculateSum512 }

两个函数逐行遍历、只累加每行前八列。实现代码见 observer-effect/main.go。直觉上两者耗时应该相近（都只遍历前 8 列），于是写基准测试对比。矩阵只在循环外创建一次，用ResetTimer排除创建开销：

const rows = 1000 var res int64 func BenchmarkCalculateSum512(b *testing.B) { var sum int64 s := createMatrix512(rows) // Create a matrix of 512 columns b.ResetTimer() for i := 0; i < b.N; i++ { sum = calculateSum512(s) } res = sum } func BenchmarkCalculateSum513(b *testing.B) { var sum int64 s := createMatrix513(rows) // Create a matrix of 513 columns b.ResetTimer() for i := 0; i < b.N; i++ { sum = calculateSum513(s) } res = sum }

结果却出乎意料（书中机器的输出）：

cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkCalculateSum512-4 81854 15073 ns/op BenchmarkCalculateSum513-4 161479 7358 ns/op

513 列版本居然快了约 50%！明明只遍历前八列，为什么列数会影响？要理解这一点，需要了解 CPU 缓存的基本原理。

底层原理：CPU 缓存与缓存行

CPU 通常由多级缓存组成（常见为 L1、L2、L3），缓存能降低访问主内存的平均代价。在特定条件下，CPU 会把主内存中的数据预取并复制到 L1。本例中，CPU 试图把calculateSum关心的那部分矩阵（每行的前八列）取进 L1。问题在于：513 列的矩阵能放进缓存，而 512 列的矩阵放不进去，于是 512 列版本产生更多缓存未命中（cache miss），执行更慢。（为什么列数之差会导致这种差异，本书 mistake #91 "Not understanding CPU caches" 有专门讨论。）

症结与修复

基准测试的核心问题在于：两个 benchmark 都在反复复用同一块矩阵。函数被重复调用成千上万次后，我们测的早已不是"函数处理一块全新矩阵"的耗时，而是"函数处理一块数据子集已在缓存里的矩阵"的耗时。calculateSum513缓存未命中更少，所以显得更快——这就是观察者效应：因为反复观察一个 CPU 密集函数，缓存机制显著干扰了结果。

修复方法是在每个循环迭代里重新创建矩阵，而不是复用同一份：

func BenchmarkCalculateSum512(b *testing.B) { var sum int64 for i := 0; i < b.N; i++ { b.StopTimer() s := createMatrix512(rows) // Create a new matrix during each loop iteration b.StartTimer() sum = calculateSum512(s) } res = sum }

每轮迭代都创建新矩阵（创建操作被StopTimer/StartTimer排除在计时之外）。重新运行（并相应调小benchtime，否则耗时过长）后，两个结果明显接近：

cpu: Intel(R) Core(TM) i5-7360U CPU @ 2.30GHz BenchmarkCalculateSum512-4 1116 33547 ns/op BenchmarkCalculateSum513-4 998 35507 ns/op

正确的结论是：在每次接收全新矩阵的情况下，512 列与 513 列版本性能相当，而不是"513 列更快"。仓库 observer-effect/main_test.go 同时保留了这两种写法（_1后缀为复用矩阵版本，_2后缀为每次重建矩阵版本），方便读者直接对比运行。

一般性原则：观察被测函数本身就可能带来显著的结果差异，尤其在 CPU 密集的微基准测试中，底层优化（缓存等）影响很大。强制在每次迭代中重新创建数据，是防止观察者效应的有效手段。

总结：写出可信 Benchmark 的四条守则

把《100 Go Mistakes》第 89 节与仓库源码对照，可以得到一套可落地的基准测试检查清单：

最后强调两点：其一，性能结论必须限定在"特定 Go 版本、特定机器、特定用法"的范围内，不能随意外推到生产环境；其二，基准测试只是优化工作的起点——得到可信结果之后，仍要回到真实业务场景去验证收益。如果你希望进一步探索本书其他相关主题，可继续阅读仓库中同系列章节 docs/92-false-sharing.md（并发下的伪共享问题）和 docs/98-profiling-execution-tracing.md（性能剖析与执行追踪）。

• 示例工程