RunParallel 是 Go testing 中 testing.B 的方法，用于多 goroutine 并行基准测试；适用于测共享资源并发性能（如连接池、缓存），需通过 b.RunParallel 调用并依赖 testing.PB.Next 控制迭代。
RunParallel 是什么，什么时候该用它
RunParallel 是 Go testing 包中 *testing.B 类型的方法，专用于**多 goroutine 并行执行基准测试逻辑**。它不适用于普通单元测试（*testing.T 没有这个方法），也不适合想测串行吞吐或单次耗时的场景——它测的是「在多个 goroutine 协同下，单位时间内能完成多少工作」。
典型适用场景：测试带共享资源的并发代码，比如连接池、缓存、线程安全队列、HTTP 客户端复用等。你关心的不是单个请求多快，而是「10 个 goroutine 一起压时，整体 QPS 能到多少」。
怎么正确调用 RunParallel
必须在 BenchmarkXxx 函数体内、通过 b.RunParallel 调用，传入一个接受 *testing.PB 的函数。关键点：
-
*testing.PB提供Next方法控制迭代节奏，**不能自己写 for 循环**，否则会漏统计或 panic - 每个 goroutine 独立拿到
*testing.PB实例，Next是线程安全的 - 基准测试总迭代次数由
b.N决定，RunParallel会自动分摊给所有 goroutine
func BenchmarkConcurrentMap(b *testing.B) {
m := sync.Map{}
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
m.Store("key", "value")
m.Load("key")
}
})
}
常见错误：误用 b.N 或忽略 PB.Next
错误写法会导致结果失真甚至 panic：
立即学习“go语言免费学习笔记（深入）”；
- 直接用
for i := 0; i —— 多个 goroutine 同时跑满 <code>b.N次，总执行次数远超预期，BenchmarkResult中的ns/op完全不可信 - 忘记调用
pb.Next()—— goroutine 无限循环，go test -bench永不结束 - 在
RunParallel外部做初始化（如新建 map），但没加锁或没考虑并发安全 —— 基准测试本身会崩溃，不是被测逻辑的问题
正确姿势：所有共享初始化放 b.ResetTimer() 前，所有并发操作封装进 RunParallel 回调，并只靠 pb.Next() 驱动。
并行度控制和性能观察要点
RunParallel 默认启动的 goroutine 数量等于 GOMAXPROCS（通常为 CPU 核心数），**无法直接指定数量**。如需对比不同并发度的影响，得手动改 GOMAXPROCS 环境变量或用 runtime.GOMAXPROCS，再跑多次 benchmark：
func BenchmarkWithCustomGOMAXPROCS(b *testing.B) {
orig := runtime.GOMAXPROCS(2)
defer runtime.GOMAXPROCS(orig)
// ... then b.RunParallel(...)
}
观察重点不是 ns/op，而是 MB/s（如果涉及内存）或原始 ops/sec。同时注意：Allocs/op 和 B/op 在并行下可能因 GC 压力变化而波动更大，单看数值易误判。
真正容易被忽略的是：RunParallel 测试的是「协作效率」，一旦被测逻辑里有强竞争（比如全局 mutex），增加 goroutine 数反而让 ops/sec 下降——这时看到负向扩展性，恰恰说明你找到了瓶颈。
