Go基准测试如何运行_go test bench参数解析

go test -bench=. 执行当前包所有Benchmark函数，需加-benchmem看内存分配，-benchtime和-count提升结果稳定性，b.N由框架自动调节。

go test -bench=. 是最常用的基准测试命令

直接运行 go test -bench=. 就能执行当前包下所有以 Benchmark 开头的函数。注意这个点（.）是正则表达式，表示“匹配任意字符串”，不是通配符或文件名。它会扫描所有 *_test.go 文件，找到符合命名规则的函数并执行。

常见错误是漏掉 -bench 参数，只写 go test —— 这默认只跑单元测试（Test* 函数），基准测试完全不会触发。

• 想只测某一个函数？用 go test -bench=BenchmarkSum（注意大小写和拼写必须完全一致）
• 怕单元测试干扰输出？加 -run=^$ 或 -run=none，确保不执行任何 Test* 函数
• 测试文件不在当前目录？需显式指定包路径，例如 go test ./pkg/math -bench=.

-benchmem 要加，否则看不到内存分配真相

-benchmem 不是可选彩蛋，而是性能分析的刚需开关。不加它，你只能看到耗时（ns/op），但完全不知道函数是否在疯狂分配内存——而 GC 压力往往比 CPU 更伤实际吞吐。

加上后输出会多出两列：X B/op 和 Y allocs/op。比如 112 B/op 3 allocs/op 表示每次调用平均分配 112 字节、触发 3 次堆分配。这对识别切片预分配、避免闭包捕获、判断是否该用 sync.Pool 极其关键。

• 分配量突增？检查是否在循环里反复 make([]T, n) 或构造新 map
• allocs/op > 0 但 B/op = 0？可能是小对象逃逸到堆，用 go build -gcflags="-m" 看逃逸分析
• 想压测 GC 影响？配合 -benchtime=10s 延长运行时间，让 GC 有足够机会介入

b.N 不是你能手动设的，但可以靠 -count 和 -benchtime 控制稳定性

b.N 是测试框架自动调节的迭代次数，目标是让单次基准测试总耗时接近 1 秒（默认值）。它从 1 开始试跑，按序列 1, 2, 5, 10, 20, 50, 100... 递增，直到耗时稳定且满足精度要求。你不能、也不该在代码里写 b.N = 10000 —— 这会破坏统计意义。

真正可控的是外部参数：

• -benchtime=3s：让每次测试至少跑够 3 秒，减少单次波动影响
• -count=5：重复整个基准测试 5 次，go test 默认只跑 1 次，单次结果容易受系统抖动干扰
• -cpu=1,2,4：分别测试单核/双核/四核下的表现，尤其对并发逻辑（如 sync.Map）很重要

实操建议：日常调优用 go test -bench=. -benchmem -benchtime=3s -count=3，结果更可信。

并发基准测试必须用 b.RunParallel，别手写 goroutine

想测高并发场景？千万别在 for i := 0; i 里自己起 goroutine——这会导致 goroutine 数量失控、调度混乱，结果毫无参考价值。

正确姿势是用 b.RunParallel，它由测试框架统一管理 worker 数量（默认等于 GOMAXPROCS），每个 worker 持续调用 pb.Next() 直到完*部 b.N 次工作。这样既真实模拟并发负载，又保证总操作数可控。

func BenchmarkMapStoreParallel(b *testing.B) {
	m := sync.Map{}
	b.RunParallel(func(pb *testing.PB) {
		for pb.Next() {
			m.Store("key", "value")
		}
	})
}

• 想限制并发度？用 b.SetParallelism(n)（n 是 worker 数），而不是改 GOMAXPROCS
• 初始化开销大？仍需在 b.RunParallel 外做，并用 b.ResetTimer() 排除
• 结果里的 -8 后缀不是 CPU 核心数，而是当时生效的 GOMAXPROCS 值，可通过 -cpu 参数覆盖

最容易被忽略的一点：基准测试里所有被测逻辑的返回值，必须被实际使用（比如赋给全局变量 blackhole 或参与后续计算），否则 Go 编译器可能直接优化掉整条调用链——你测的根本不是原函数，而是一段空操作。