Go 官方推荐用 testing.B.RunParallel 进行并发基准测试，它自动分配 goroutine、复用 B.N 为总迭代次数，并通过 sync.WaitGroup 同步；函数需接收 *testing.PB 参数以安全分发任务。
Go 的 testing 包原生支持并发基准测试，但直接用 go test -bench 跑并发代码容易误测——默认的 Benchmark 函数是串行执行的，不自动并行，也不会帮你控制 goroutine 数量或同步逻辑。
用 testing.B.RunParallel 启动真正并发的基准测试
这是 Go 官方推荐的并发基准写法。它会自动分配 goroutine 到多个 P 上运行，并复用 B.N 作为总迭代次数（不是每个 goroutine 跑 B.N 次）。
-
RunParallel内部使用sync.WaitGroup等待所有 worker 完成，你无需手动同步 - 传入的函数签名必须是
func(*testing.PB)，其中*testing.PB提供Next方法来安全地分发迭代任务 - 不要在
RunParallel外部启动 goroutine；否则B.N统计会失真，-benchmem也会不准
func BenchmarkConcurrentMapRead(b *testing.B) {
m := make(map[int]int)
for i := 0; i < 1000; i++ {
m[i] = i * 2
}
b.RunParallel(func(pb *testing.PB) {
for pb.Next() {
_ = m[123]
}
})
}避免在 Benchmark 中混用 time.Sleep 或阻塞 I/O
基准测试的目标是测量 CPU-bound 或 lock-bound 的真实开销，加入睡眠或网络调用会让结果反映的是等待时间而非并发逻辑性能。
-
time.Sleep会导致B.N被严重低估（因为大部分时间在睡），ns/op失去可比性 - 如果必须模拟 I/O，改用内存缓冲（如
bytes.Buffer）或预生成数据，确保被测逻辑是纯计算/同步部分 - 对 channel 操作做基准时，注意缓冲区大小：无缓冲 channel 会强制同步等待，有缓冲则可能掩盖竞争问题
用 -cpu 和 -benchmem 观察调度与内存行为
并发性能不只是快慢问题，更要看资源利用是否合理。Go 的 go test 提供了关键参数：
立即学习“go语言免费学习笔记（深入）”；
-
-cpu=1,2,4,8：指定 GOMAXPROCS 值，观察扩展性拐点。比如吞吐在 4 个 P 之后不再上升，说明存在锁争用或共享内存瓶颈 -
-benchmem：显示每次操作的平均内存分配次数（B/op）和字节数（allocs/op）。高分配常意味着频繁创建对象（如闭包、临时 map），会加剧 GC 压力 - 结合
pprof：加-cpuprofile=cpu.out和-memprofile=mem.out，用go tool pprof查看热点，特别是runtime.futex或sync.runtime_SemacquireMutex占比高时，基本就是锁瓶颈
小心 sync.Map 的“假优势”和适用边界
很多人一测 sync.Map 就比普通 map + RWMutex 快，但这只在读多写少且 key 分布稀疏时成立。它的设计目标不是通用高性能，而是降低 GC 压力和避免全局锁。
-
sync.Map的Load不分配内存，但Store可能触发内部 map 扩容和键值复制；高频写入反而更慢 - 它不支持遍历（
Range是快照，且无法保证一致性），也不支持删除后立即释放内存 - 若你的场景是固定 key 集合、写一次读多次，用
map+sync.RWMutex通常更可控；若 key 动态增长且读占比 >95%，再考虑sync.Map
并发基准测试最难的不是跑起来，而是确认你测的确实是想优化的那一层——是锁竞争？GC 压力？还是调度器抢占？别让 B.N 的数字骗过自己。
