Go 的 testing 包通过 b.RunParallel 支持并发基准测试，需用 pb.Next() 分配任务以避免竞争；关键看 ns/op 和 B/op 随并发度变化趋势，配合 pprof 和 profile 识别锁争用、内存分配与 GC 瓶颈。
Go 的 testing 包原生支持并发基准测试，但“parallel benchmark”并非一个独立工具，而是指通过 b.RunParallel 方法在单个基准函数内启动多个 goroutine 并发执行，从而模拟多线程负载、评估并行扩展性与潜在瓶颈。关键不在于“多线程效率”的绝对数值，而在于观察 ns/op（每次操作耗时）和 total allocs 随并发度（b.N 和 goroutine 数量）变化的趋势。
用 RunParallel 正确编写并行基准测试
必须在 b.RunParallel 内部调用 pb.Next 获取待处理任务，不能在外部预分配或共享计数器——否则会引入竞争或序列化瓶颈，测出的是锁开销而非真实性能。
- 错误写法：在闭包外定义
var i int并用atomic.AddInt64(&i, 1)计数 —— 这会强制所有 goroutine 争抢同一原子变量，严重失真 - 正确写法：每个 goroutine 调用
pb.Next()拉取独立任务索引，例如处理切片元素、生成随机输入、调用目标函数等 - 示例：测试并发 map 写入，应让每个 goroutine 写入不同 key（如
"key-"+strconv.Itoa(i)），避免哈希冲突和写锁竞争
识别典型并行瓶颈的指标模式
运行 go test -bench=. -benchmem -cpu=1,2,4,8 后，重点对比不同 GOMAXPROCS 下的 ns/op 和 B/op：
-
CPU-bound 场景下线性加速消失：当 CPU 核数翻倍，但
ns/op仅下降 30%～50%，说明存在共享资源争用（如 mutex、全局变量、sync.Pool 误用）或 false sharing -
内存分配暴增：并发度提高后
B/op显著上升，往往意味着每 goroutine 分配了本可复用的对象（如反复 new struct），或 sync.Pool 使用不当（Put/Get 不匹配、跨 goroutine 使用） -
GC 压力突增：
gc pause时间变长或 GC 次数增加，通常源于短生命周期对象爆炸式分配，需结合-gcflags="-m"查看逃逸分析
配合 pprof 定位热点与阻塞点
基准测试本身不暴露内部阻塞，需导出 profile 数据进一步分析：
立即学习“go语言免费学习笔记（深入）”；
- 添加
runtime.SetMutexProfileFraction(1)和runtime.SetBlockProfileRate(1)在func BenchmarkXxx(b *testing.B)开头启用锁和阻塞采样 - 运行
go test -bench=BenchmarkXxx -cpuprofile=cpu.prof -memprofile=mem.prof -blockprofile=block.prof - 用
go tool pprof cpu.prof查看热点函数；用go tool pprof -http=:8080 block.prof查看 goroutine 阻塞在 mutex、channel receive 或 network I/O 的位置 - 特别关注
sync.(*Mutex).Lock、runtime.gopark、chan receive等调用栈深度高的节点
避免常见误判：理解 b.N 与 goroutine 数量的关系
b.N 是整个基准循环的总迭代次数，b.RunParallel 的 func(*testing.PB) 会被多个 goroutine 并发执行，每个 goroutine 自行调用 pb.Next() 直到返回 false。因此：
- 实际执行次数 =
b.N（不变），不是 goroutine 数 × 单次循环次数 - goroutine 数量由
-cpu参数控制（如-cpu=4启动 4 个），但b.RunParallel内部默认使用runtime.GOMAXPROCS(0)的值，也可显式设置runtime.GOMAXPROCS(n) - 若任务粒度过小（如每次只做一次加法），调度开销会掩盖真实耗时，应确保单次
pb.Next()对应的工作量足够大（例如处理 100 个元素）
