Golang并发性能测试技巧解析

今日不肯埋头，明日何以抬头！每日一句努力自己的话哈哈~哈喽，今天我将给大家带来一篇《Golang并发基准测试方法解析》，主要内容是讲解等等，感兴趣的朋友可以收藏或者有更好的建议在评论提出，我都会认真看的！大家一起进步，一起学习！

基准测试中直接用 go 关键字会失效，因 testing.B 是单线程且 goroutine 不受 b.N 控制；应使用 b.RunParallel 实现正确并发压测。

基准测试里直接用 go 关键字会失效

Go 的 testing.B 基准测试函数本身是单线程执行的，b.Run 或循环体中直接起 goroutine 不会自动计入计时，也不会被 b.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
<pre class="brush:php;toolbar:false;">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
<pre class="brush:php;toolbar:false;">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 只会放大锁争用，测出来的反而是退化值。

今天关于《Golang并发性能测试技巧解析》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！