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 多轮采样。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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 做分支逻辑。
