Golang中的并发测试：如何模拟高竞争场景 Go语言Benchmark与Parallel

go benchmark需显式调用b.setparallelism(n)启用并行，n为逻辑并行度，一般设runtime.numcpu()；runparallel仅对紧随其后的调用生效；高争抢场景mutex常比rwmutex快；-benchmem需配合-count采样防干扰；waitgroup负计数因done多于add，应defer wg.done()或避免手动管理。

Go benchmark 怎么开启并行执行

默认 Benchmark 函数是串行跑的，哪怕你写 b.RunParallel，它也不会自动并行——必须显式调用 b.SetParallelism 才生效。不设这个，RunParallel 里开再多 goroutine 也只在一个 P 上调度，压根测不出竞争。

• b.SetParallelism(n) 的 n 是“逻辑并行度”，不是 goroutine 数量；它控制 RunParallel 内部启动多少 worker 协程，一般设为 CPU 核数（runtime.NumCPU()）较合理
• 如果 n=1，RunParallel 退化为单协程循环，和直接 for 循环没区别
• 注意：这个设置只对紧随其后的 RunParallel 生效，多个 RunParallel 需各自设

并发测试里 sync.Mutex 为什么比 RWMutex 还快

在高争抢、读写比接近 1:1 的场景下，RWMutex 的额外状态维护和唤醒逻辑反而成瓶颈。它的写锁会阻塞所有读请求，而 Mutex 虽然更“粗”，但调度更简单，上下文切换开销更低。

• 实测常见误区：用 RWMutex 测“读多写少”没问题，但一换成“写频繁+小临界区”，Mutex 常胜出
• sync/atomic 在纯计数类场景（如累加器）几乎总是优于任何锁，但无法用于复杂结构保护
• 别依赖文档说“RWMutex 读性能好”就默认它更适合并发 benchmark——得看你的临界区大小、持有时间、goroutine 数量

go test -bench 的 -benchmem 和 -count 参数怎么配合用

-benchmem 显示每次操作的内存分配次数和字节数，但它默认只跑一次基准测试；而单次运行受 GC、缓存预热等干扰大，数据波动剧烈。这时候必须配 -count 多轮采样。

• go test -bench=. -benchmem -count=5 会跑 5 次，输出每轮的 allocs/op 和 B/op，最后再给个平均值
• 如果只用 -benchmem 不加 -count，看到的可能是冷启动时的异常高分配，误判为内存泄漏
• -count 不影响 RunParallel 的并发行为，它只是重复整个 benchmark 函数多次

并发 benchmark 中 panic: sync: negative WaitGroup counter 的原因

这是典型的 WaitGroup 使用错误：Done() 调用次数超过 Add()，常发生在 RunParallel 里 goroutine 提前退出或 panic 后没做清理。

立即学习“go语言免费学习笔记（深入）”；

• 别在 RunParallel 的 fn 里直接 wg.Done() —— 应该用 defer wg.Done()，否则 panic 时不会执行
• 更稳妥的做法是避免在 RunParallel 里手动管理 WaitGroup，改用 b.N 控制迭代，让框架自己调度
• 如果必须用 WaitGroup，确保 Add 在 RunParallel 外调用，且数值等于预期 goroutine 总数（b.GOMAXPROCS * b.N 不可靠，用 b.SetParallelism 后的实际 worker 数为准）

真实压力下，b.N 的值不等于你看到的循环次数——它会被 runtime 动态调整以满足目标运行时长（默认 1s），所以临界区内不要依赖 b.N == 1000 做分支逻辑。