Go testing.B.RunParallel 的计时控制与 goroutine 局部状态设计

写 Go 并行基准时，testing.B.RunParallel 的关键不是“开几个 goroutine”，而是先把计时边界和状态边界分开：计时器只在并行回调外统一控制；每个 goroutine 在进入 pb.Next() 循环前准备自己的缓冲区或临时对象；最终把 ns/op 理解为整个并行基准的墙钟时间。这样写出来的结果才不会混入初始化成本，也不会因为共享临时状态产生锁竞争。

先记住三个结论：RunParallel 默认按 GOMAXPROCS 创建并行工作单元；StartTimer、StopTimer、ResetTimer 在回调内会影响整个基准，不能当作单个 goroutine 的计时器；输出的 ns/op 不是各 goroutine 耗时相加，而是并行执行的墙钟口径。

RunParallel 的计时边界先划清

官方文档把 RunParallel 描述为把 b.N 次迭代分配给多个 goroutine。回调函数会在每个 goroutine 中执行，因此初始化可以放在回调开头；但 B 的计时方法是全局效果，不能在某个回调里“暂停自己”。需要排除准备成本时，在调用 RunParallel 前停止计时，准备输入后再启动；并行工作结束后再停止计时处理收尾。

func BenchmarkParseParallel(b *testing.B) {
	// 这段输入准备不应混入并行操作的计时结果。
	b.StopTimer()
	input := []byte(`name=go&mode=parallel`)
	b.StartTimer()

	b.RunParallel(func(pb *testing.PB) {
		// 每个 goroutine 独享临时缓冲区，避免并发写入同一对象。
		buf := make([]byte, 0, len(input))
		for pb.Next() {
			buf = append(buf[:0], input...)
			_ = parsePair(buf) // 只保留本例的被测调用。
		}
	})

	// 这里的收尾不属于被测区间；不要把 StopTimer 放进回调。
	b.StopTimer()
}

这段代码的重点是位置：StopTimer 和 StartTimer 属于外层 B，回调内部只负责局部状态和迭代。若准备成本本来就是生产路径的一部分，就不要为了好看而排除它，关键是让测量口径与真实任务一致。

用 pb.Next 分摊 b.N 次迭代

pb.Next() 返回 true 时，当前 goroutine 取得下一次工作；返回 false 就退出。不要手动把 b.N 除以 goroutine 数，也不要在回调里再调用 b.Run。前者会让尾部工作分配失真，后者与 RunParallel 的调度模型不匹配。

局部状态应在循环外创建、在循环内复用。例如缓冲区、编码器或一次性解析工作区可以属于当前 goroutine；共享计数器、结果集合则必须使用原子操作、锁或其他明确的并发协议。若被测 API 本身要求共享对象，要把“共享对象带来的同步成本”作为测试对象的一部分，而不是偷偷复制成另一个场景。

并行度与 ns/op 的结果口径

CPU 密集型基准通常先使用默认并行度；需要让非 CPU 密集型工作产生更多并行请求时，才在 RunParallel 前调用 SetParallelism(p)。它把工作单元数量设置为 p × GOMAXPROCS，小于 1 的参数没有效果。每次改变并行度，都应保留同一输入和同一被测逻辑，否则结果无法比较。

因此，看到 ns/op 变小，只能说明在当前机器、输入和并行度下墙钟完成速度更快，不能直接推导出 CPU 消耗也更低。标题里的“计时控制”和“局部状态”必须一起看：前者决定测到了什么，后者决定并发时是否引入额外争用。

相关问题

RunParallel 回调里能调用 ResetTimer 吗？

不建议。官方说明这些计时方法具有全局效果；需要重置时，把它放在并行回调之外，并让整个基准使用一致的计时区间。

SetParallelism 应该默认加上吗？

不应该。先用默认的 GOMAXPROCS 建立基线；只有非 CPU 密集型任务确实需要更高并发时，再增加 p 并单独比较。