Go语言Mutex与Atomic基准测试中alloc/op数值异常疑问

核心问题：基准测试写法误用了b.N #

你当前的基准测试逻辑完全混淆了Go基准测试中b.N的作用：

• b.N的本质是单次基准循环要执行的目标操作次数，而非要创建的goroutine数量。
• 你在子测试闭包里直接循环b.N次创建goroutine，相当于把“创建N个goroutine并完成所有计数操作”作为一次基准迭代，而非“执行一次加锁/原子计数”作为最小基准单元。这直接导致alloc/op统计的是每个goroutine创建带来的分配，而非每次计数操作的分配，完全偏离了你的测试目标。

另外，全局复用sync.WaitGroup会导致子测试之间状态污染，比如第一次测试的wg.Done()可能干扰第二次测试的等待逻辑，引发不可预期的行为。

内存分配计数的具体原因 #

你看到的3 allocs/op和2 allocs/op主要来自两部分：

1. goroutine创建的固有分配：每个go func()会在堆上分配goroutine的控制结构体、初始栈帧等，这是pprof捕获到的主要分配来源。
2. 逃逸变量的一次性分配：counterLock、counter、atomicCounter被goroutine闭包捕获，编译器无法确定它们的生命周期会早于goroutine结束，因此被强制逃逸到堆上。这些变量仅在BenchmarkCounter启动时分配一次，但因为你的基准测试把“创建N个goroutine”作为一次迭代，总分配次数包含了这次一次性分配，分摊后虽然趋近于0，但goroutine本身的多次分配会主导最终的alloc/op数值。

修正后的基准测试代码 #

下面两种方案分别对应串行和并发场景的基准测试，符合Go的最佳实践：

方案1：串行性能对比（单goroutine执行所有操作） #

const numCalls = 1000

func BenchmarkCounter(b *testing.B) {
    b.Run("mutex", func(b *testing.B) {
        var counterLock sync.Mutex
        var counter int
        // 把总操作次数调整为b.N * numCalls，确保基准统计的是单次计数操作的开销
        b.N *= numCalls
        for i := 0; i < b.N; i++ {
            counterLock.Lock()
            counter++
            counterLock.Unlock()
        }
    })

    b.Run("atomic", func(b *testing.B) {
        var atomicCounter atomic.Int64
        b.N *= numCalls
        for i := 0; i < b.N; i++ {
            atomicCounter.Add(1)
        }
    })
}

方案2：并发性能对比（用b.RunParallel模拟真实并发） #

const numCalls = 1000

func BenchmarkCounter(b *testing.B) {
    b.Run("mutex", func(b *testing.B) {
        var counterLock sync.Mutex
        var counter int
        // RunParallel会自动管理并发goroutine，无需手动创建WaitGroup
        b.RunParallel(func(pb *testing.PB) {
            for pb.Next() {
                for i := 0; i < numCalls; i++ {
                    counterLock.Lock()
                    counter++
                    counterLock.Unlock()
                }
            }
        })
    })

    b.Run("atomic", func(b *testing.B) {
        var atomicCounter atomic.Int64
        b.RunParallel(func(pb *testing.PB) {
            for pb.Next() {
                for i := 0; i < numCalls; i++ {
                    atomicCounter.Add(1)
                }
            }
        })
    })
}

修正后的统计说明 #

• 方案1中，counterLock等变量不会逃逸到堆上（编译器可明确其生命周期），整个基准循环无额外内存分配，alloc/op会趋近于0。
• 方案2中，b.RunParallel会复用worker goroutine，大幅减少goroutine创建带来的分配，alloc/op会更贴近真实并发场景下的计数操作开销。

内容的提问来源于stack exchange，提问作者vtm11