go基准测试需设gomaxprocs并用b.runparallel才能真实模拟多线程调度、锁竞争等场景；仅设gomaxprocs不够，必须配合b.runparallel启动多goroutine；过高值反致性能下降，建议上限为runtime.numcpu()。
Go基准测试为啥要关心GOMAXPROCS
因为testing.B默认在单个OS线程上跑，但真实服务往往并发运行在多个线程；不调GOMAXPROCS就测不出调度开销、锁竞争、cache line false sharing这些真问题。
常见错误现象：go test -bench=.跑出来的数字看着很高，一上线就卡顿——压测时没模拟多线程调度压力，结果失真。
- 基准测试前手动设
GOMAXPROCS：在BenchmarkXxx函数开头加runtime.GOMAXPROCS(n) - 别依赖环境变量：不同机器
GOMAXPROCS默认值可能不同（如linux是CPU数，macos有时会限为2），必须显式控制 - 测试多个值：比如分别试
1、4、8、runtime.NumCPU()，看吞吐是否线性增长或何时拐点出现
如何让BenchMark真正跑在多线程上
光设GOMAXPROCS不够——testing.B的b.RunParallel才是触发多goroutine+多OS线程的关键。否则即使GOMAXPROCS>1，也只用一个goroutine串行跑。
使用场景：测并发安全的数据结构（如sync.map）、带锁逻辑、channel密集交互、GC压力等。
立即学习“go语言免费学习笔记（深入）”；
-
b.RunParallel内部会启动多个goroutine，每个goroutine被调度器分配到可用OS线程，实际触发多线程执行 - 注意：
b.RunParallel里不能调b.ResetTimer或b.ReportAllocs，这些只能在外部调 - 示例片段：
func BenchmarkConcurrentMap(b *testing.B) { runtime.GOMAXPROCS(4) m := sync.Map{} b.RunParallel(func(pb *testing.PB) { for pb.Next() { m.Store("key", 42) m.Load("key") } }) }
GOMAXPROCS设太高反而拖慢基准测试
不是越多越快。OS线程切换、内存带宽争抢、TLB miss都会在超线程数后明显上升，尤其在小对象高频分配场景下。
性能影响：在i7-8700K（6核12线程）上，对一个简单原子计数器atomic.AddInt64，GOMAXPROCS=24比=12慢15%——额外线程没活干，纯抢调度器资源。
- 建议上限设为
runtime.NumCPU()，除非你明确想测超售调度行为 - 避免在CI里硬编码大数值：不同CI节点CPU数不同，会导致结果不可比
- 如果基准中用了
time.Sleep或阻塞I/O，高GOMAXPROCS可能掩盖真实瓶颈（线程挂起太多，反而让CPU更空闲）
Mac和Linux下基准测试结果差异大的原因
根本不在Go本身，而在底层线程调度策略和timer精度：mach_absolute_time（macOS）和clock_gettime(CLOCK_MONOTONIC)（Linux）实现不同，加上macOS默认限制后台进程CPU时间片，导致b.N实际执行次数波动更大。
容易踩的坑：在Mac上跑出“比Linux快2倍”的假象，其实是timer抖动让b.N被低估了——同一段代码在Linux上跑了100万次，在Mac上可能只跑了60万次就超时，于是平均耗时显得更低。
- 跨平台对比务必加
-benchmem -count=5，取多次中位数，排除单次抖动 - 禁用macOS节能策略：
sudo pmset -a disablesleep 1（测试完记得恢复） - 用
go tool trace看Proc状态分布，确认是否真有多个P在同时运行，而不是“看起来并发实则排队”
事情说清了就结束