Golang在基准测试中引入并发的方式
基准测试中直接用 go 关键字会失效，因 testing.B 是单线程且 goroutine 不受 b.N 控制；应使用 b.RunParallel 实现正确并发压测。
基准测试里直接用 go 关键字会失效
Go 的 testing.B 基准测试函数本身是单线程执行的，b. 或循环体中直接起 goroutine 不会自动计入计时，也不会被 
Runb.N 控制——结果既不准，也容易因竞态或提前退出导致 panic。真实并发压测必须让 goroutine 的生命周期与基准框架对齐。
正确方式：用 b.RunParallel 驱动并发执行
b.RunParallel 是 Go 标准库专为并发基准设计的接口，它内部管理 goroutine 池、分摊 b.N 迭代次数，并确保所有 worker 完成后才结束计时。适用于可并行化、无共享状态或已加锁的逻辑。
- 每个 worker 执行一个闭包，闭包内通常用
for i := range b.N或for i := 0; i —— 实际迭代数由框架动态分配，不等于你写的数字 - 不能在闭包里调用
b.ResetTimer()或b.StopTimer()，这些方法只在顶层BenchmarkXxx函数中有效 - 若被测函数含全局状态（如 map、计数器），需自行同步；
b.RunParallel不提供隔离
func BenchmarkConcurrentAdd(b *testing.B) {
var sum int64
var mu sync.Mutex
b.RunParallel(func(pb *testing.PB) {
for pb.Next() { // 注意：不是 for i := 0; i < b.N; i++
mu.Lock()
sum++
mu.Unlock()
}
})}
需要精确控制 goroutine 数量？手动建池 + b.ResetTimer()
当你要固定启动 8 个 goroutine、每个跑满 b.N 次，且想排除启动开销时，就得绕过 RunParallel，自己管理。关键点是：计时器必须在所有 goroutine 启动完毕后才开启，且等全部结束才停止。
- 用
b.ResetTimer()清除初始化耗时（如 channel 创建、切片预分配） - 用
sync.WaitGroup确保主 goroutine 等待所有 worker 结束 - 避免在 worker 中调用
b.N—— 它只是总次数，需均分，比如each := b.N / runtime.NumCPU()
func BenchmarkFixedGoroutines(b *testing.B) {
const workers = 4
each := b.N / workers
var wg sync.WaitGroup
b.ResetTimer() // 从这里开始计时
for i := 0; i < workers; i++ {
wg.Add(1)
go func() {
defer wg.Done()
for j := 0; j < each; j++ {
time.Sleep(10 * time.Microsecond) // 模拟工作
}
}()
}
wg.Wait()}
别忽略 -cpu 和 -benchmem 参数的影响
go test -bench=. -cpu=1,2,4,8 会让同一基准函数按不同 GOMAXPROCS 运行多次，但 b.RunParallel 的并发度默认由运行时决定（通常 ≈ GOMAXPROCS），而手动启 goroutine 的数量完全由代码硬编码。两者行为不等价。
- 如果测试依赖 CPU 密集型计算，
-cpu会影响RunParallel的吞吐表现，但不会改变你手动写的go func(){...}()数量 -
-benchmem会统计每次操作的内存分配，但并发场景下 total allocs 可能被多个 goroutine 共同贡献，数值不代表单次调用开销 - 真实服务压测建议结合
pprof查看 goroutine block profile，基准测试本身看不出锁竞争细节
并发基准不是起 goroutine 就完事。最常被跳过的一步是：没确认被测逻辑是否真能并行——比如带全局 mutex 的串行逻辑，用 RunParallel 只会放大锁争用，测出来的反而是退化值。
