Go基准测试通过testing.B量化代码性能，使用go test -bench=测量ns/op、B/op和allocs/op，区分于单元测试的正确性验证，需隔离被测代码、用真实数据集并关注内存分配与并发表现。
golang的性能测试，尤其通过基准测试（benchmarking）来实现，本质上就是一套系统化的方法，用以量化我们代码的执行效率。它不是简单地跑一遍代码看看有没有错，而是要精确地测量某个函数或操作在特定条件下的运行时间、内存分配情况，从而帮助我们找出性能瓶颈，指导优化方向。这就像给代码做一次全面的体检，看看哪个环节需要“锻炼”或者“调整饮食”。
testing
包。你不需要引入额外的第三方库，Go语言的设计者已经为我们提供了非常强大且易用的基准测试框架。
最直接的实践方式，就是创建一个以
_test.go
结尾的文件，比如
my_package_test.go
，然后在里面定义一个或多个基准测试函数。这些函数的命名必须遵循
BenchmarkXxx
的格式，并且接受一个
*testing.B
类型的参数。
package mypackage import ( "testing" "time" ) // 一个简单的示例函数，我们想测试它的性能 func SomeExpensiveOperation(n int) int { sum := 0 for i := 0; i < n; i++ { sum += i } // 模拟一些耗时操作 time.Sleep(time.Microsecond * time.Duration(n/1000)) return sum } // BenchmarkSomeExpensiveOperation 是对 SomeExpensiveOperation 的基准测试 func BenchmarkSomeExpensiveOperation(b *testing.B) { // b.N 是基准测试框架为我们确定的循环次数，确保测量结果的统计学意义 for i := 0; i < b.N; i++ { SomeExpensiveOperation(10000) // 每次迭代都执行这个操作 } } // 另一个例子，可能涉及内存分配 func generateSlice(size int) []int { s := make([]int, size) for i := 0; i < size; i++ { s[i] = i } return s } func BenchmarkGenerateSlice(b *testing.B) { b.ReportAllocs() // 报告内存分配情况 for i := 0; i < b.N; i++ { generateSlice(1000) } } // 如果你的测试函数有准备阶段，可以用 b.ResetTimer() 来排除准备时间 func BenchmarkSomeOperationWithSetup(b *testing.B) { // 假设这里有一些耗时的初始化工作 _ = make([]byte, 1024*1024) // 比如分配一个大缓冲区 b.ResetTimer() // 重置计时器，确保只测量下面的循环 for i := 0; i < b.N; i++ { // 实际要测试的代码 _ = SomeExpensiveOperation(100) } } // 有时候你可能想在测试过程中暂停计时器 func BenchmarkOperationWithPause(b *testing.B) { for i := 0; i < b.N; i++ { b.StopTimer() // 暂停计时器 // 模拟一个不希望计入性能测量的操作，比如数据准备 time.Sleep(time.Millisecond) b.StartTimer() // 重新开始计时 _ = SomeExpensiveOperation(10) } }
运行这些基准测试，你只需要在命令行中导航到你的包目录，然后执行
go test -bench=.
。这里的
.
表示运行当前包下的所有基准测试。你也可以指定特定的基准测试，比如
go test -bench=SomeExpensiveOperation
。
立即学习“go语言免费学习笔记（深入）”；
Golang基准测试与单元测试有何不同？
在我看来，这是一个经常被混淆但又至关重要的问题。简单来说，单元测试（Unit Test）关注的是代码的“正确性”，它要确保你的函数在给定输入时能产生预期的输出，像个细心的质检员。而基准测试（Benchmark Test）则关注代码的“效率”，它要衡量你的函数跑得有多快、消耗多少资源，更像个专业的赛车手，追求极致的速度和能耗比。
从代码层面看，它们都存在于
_test.go
文件中，但使用的
testing
包的类型不同。单元测试函数接收
*testing.T
，你可以用
t.Error()
、
t.Fail()
等方法来报告测试失败。而基准测试函数接收
*testing.B
，它提供了
b.N
（循环次数）、
b.ResetTimer()
、
b.ReportAllocs()
等方法，专注于时间、内存的测量。
运行方式上，
go test
默认会执行单元测试，而要运行基准测试，你必须显式地加上
-bench
参数。它们的输出也截然不同：单元测试会告诉你哪些通过了，哪些失败了；基准测试则会输出每秒操作数（ops/sec）、每次操作耗时（ns/op）、内存分配情况等性能指标。所以，它们的目的是互补的，一个保证代码行为正确，另一个保证代码运行高效。
如何编写高效且有代表性的Go基准测试？
编写一个有用的基准测试，其实比想象中要复杂一些。它不仅仅是把代码扔进
b.N
循环那么简单，更重要的是要让测试结果能够真实反映代码在实际应用中的表现。
首先，隔离被测代码是基本原则。你的基准测试应该只测量你真正想优化的那部分逻辑，避免外部因素（如网络I/O、文件读写、数据库操作）的干扰。如果你的函数依赖这些，可以考虑使用mock对象或者在测试前准备好数据，然后在
b.ResetTimer()
之后再开始计时。我经常看到有人在基准测试里包含了数据库查询，这其实测的是数据库性能，而不是你的Go代码。
其次，使用真实且多样的数据集。一个只用固定小数据集跑出来的“高性能”，在面对实际生产环境中的大数据量时可能瞬间崩溃。所以，考虑你的函数会处理的数据范围，包括边界情况（空、只有一个元素）、平均情况和极端情况。你可以通过在
b.N
循环外部生成数据，然后在循环内部使用这些数据来模拟。
另外，利用
b.RunParallel
进行并发测试。如果你的函数设计为并发安全，并且在实际应用中会以高并发的方式被调用，那么
b.RunParallel
能更好地模拟这种场景。它会在多个goroutine中并行执行基准测试，这对于评估锁竞争、并发瓶颈非常有帮助。
// 假设有一个并发安全的计数器 type ConcurrentCounter struct { count int mu sync.Mutex } func (c *ConcurrentCounter) Increment() { c.mu.Lock() c.count++ c.mu.Unlock() } func BenchmarkConcurrentIncrement(b *testing.B) { counter := &ConcurrentCounter{} b.RunParallel(func(pb *testing.PB) { for pb.Next() { counter.Increment() } }) }
最后，注意内存分配。
b.ReportAllocs()
是一个非常棒的工具，它可以让你看到每次操作分配了多少内存，这对于Go语言的性能优化至关重要，因为过多的内存分配会导致GC压力增大，从而影响性能。有时候，减少哪怕一点点不必要的内存分配，都能带来显著的性能提升。
解读Go基准测试结果，我们应该关注哪些指标？
当我们运行
go test -bench=.
之后，会看到类似这样的输出：
goos: darwin goarch: arm64 pkg: my_project/mypackage cpu: Apple M1 BenchmarkSomeExpensiveOperation-8 100000 10373 ns/op BenchmarkGenerateSlice-8 100000 10373 ns/op 8000 B/op 2 allocs/op BenchmarkSomeOperationWithSetup-8 1000000 1037 ns/op BenchmarkOperationWithPause-8 1000000 1037 ns/op BenchmarkConcurrentIncrement-8 10000000 100 ns/op PASS ok my_project/mypackage 1.234s
解读这些结果，有几个核心指标需要我们重点关注：
-
ns/op
(Nanoseconds per operation)：这是最重要的指标，它表示每次操作平均耗时多少纳秒。这个值越小越好。当你优化代码后，如果这个值显著下降，那么恭喜你，你的优化是有效的。但要注意，这个值会受到
b.N
（操作次数）的影响，Go会动态调整
b.N
以确保测量结果的稳定性。
-
ops/sec
(Operations per second)：虽然
ns/op
是更直接的度量，但
ops/sec
提供了一个更直观的吞吐量视角，表示每秒能完成多少次操作。它和
ns/op
是倒数关系，一个降低，另一个就会升高。
-
B/op
(Bytes per operation)：这个指标表示每次操作平均分配了多少字节的内存。Go的垃圾回收机制（GC）会回收不再使用的内存，但频繁的内存分配和回收会带来额外的开销。所以，减少
B/op
通常意味着降低GC压力，从而提升整体性能。
-
allocs/op
(Allocations per operation)：这个指标表示每次操作平均进行了多少次内存分配。与
B/op
类似，减少分配次数也能有效减轻GC负担。有时候，即使总分配字节数不变，减少分配次数也能带来好处，因为它减少了GC需要追踪的对象数量。
在比较不同版本的代码或不同实现方案的性能时，我强烈推荐使用
benchstat
工具。它能对多次基准测试结果进行统计分析，包括中位数、平均值、标准差等，并能清晰地显示出不同版本之间的性能差异，以及这种差异是否具有统计学意义。这比你肉眼去对比数字要可靠得多。
最后，记住，基准测试的结果并非绝对真理。它们是在特定硬件、操作系统和Go版本下测得的。在不同的环境中，结果可能会有所不同。所以，在做性能决策时，要结合实际的部署环境和业务场景来综合判断。
评论（已关闭）
评论已关闭