runtime.setmutexprofilefraction 是互斥锁竞争采样率控制器，设为0关闭采样，1表示每次竞争都记录，5表示平均每5次记录1次；需配合启用mutex profile才生效，且仅在发生真实锁竞争（等待超10ms）时采集数据。
runtime.SetMutexProfileFraction 是什么，调用它到底有没有用
它不是开关，而是采样率控制器——设为 0 表示完全关闭互斥锁竞争采样；设为 1 表示每次锁竞争都记录；设为 5 表示平均每 5 次竞争记录 1 次。但注意：这个“5 次”是运行时内部的粗略统计，不保证严格均匀。
真正起作用的前提是：你已经启用了 mutex profile（比如通过 go tool pprof 抓取 /debug/pprof/mutex），否则设了也白设。它本身不输出数据，只影响后续 profile 的数据密度。
- 生产环境建议设为
1或5，太低（如100）可能漏掉关键竞争点；太高（如1）会轻微拖慢高并发锁密集场景 - 设成负数（如
-1）会被忽略，保持默认值（0，即关闭） - 必须在程序早期调用，比如
init()或main()开头，启动 goroutine 或大量锁操作后再设，前面的竞争就丢了
为什么开了 profile 还看不到锁竞争，是不是没生效
最常见原因是：没有实际发生锁竞争。sync.Mutex 在无竞争时走快速路径，完全不触发 runtime 的竞争记录逻辑。只有当一个 goroutine 尝试获取已被占用的锁、且等待时间超过 runtime 内部阈值（约 10ms）时，才会计入 mutex profile。
- 本地测试时用单核 CPU 或
GOMAXPROCS=1容易误判——竞争不易发生，建议用多核 + 多 goroutine 高频争抢同一把锁来验证 - 检查是否真在跑锁竞争：在可疑代码段加
time.Sleep(10 * time.Millisecond)强制阻塞，再看 profile 是否有数据 - 确认抓取的是
/debug/pprof/mutex，不是/debug/pprof/profile（那是 CPU profile）或/debug/pprof/block（那是阻塞 profile）
和 block profile、trace 的区别在哪，该选哪个
mutex profile 只告诉你「哪把锁被争抢得最凶」，定位热点锁；block profile 告诉你「goroutine 在等什么资源（锁、channel、network）以及等了多久」；trace 则是全量事件流，能看清锁获取/释放的精确时序，但体积大、分析成本高。
立即学习“go语言免费学习笔记（深入）”；
- 怀疑锁拖慢整体性能 → 先看
mutex profile找出 top 锁，再结合代码看是否设计不合理（比如一把全局锁保护本可分片的数据） - 发现 goroutine 卡住不动 → 优先抓
block profile，它比 mutex 更直接反映等待行为 - 需要确认锁的获取顺序是否导致死锁或级联阻塞 → 必须用
go tool trace，因为 mutex profile 不含调用栈上下文和时序关系
线上开启 mutex profile 会不会炸内存或拖垮服务
不会炸内存，但有可测量的开销：每次记录竞争会分配少量对象、写入全局哈希表，并在 GC 时额外扫描。实测在 QPS 万级、锁竞争每秒数百次的服务上，CPU 开销增加约 0.5%~2%，内存增长可忽略（KB 级）。
- 真正危险的是开着
runtime.SetBlockProfileRate(1)或runtime.SetGCPercent(-1)这类全量采集配置，mutex profile 的粒度远比它们粗 - 如果服务本身锁竞争极少（比如每分钟不到一次），profile 几乎零开销；反之，若每秒上万次竞争，即使设为
100，采样后仍可能产生较多数据，建议配合pprof.Lookup("mutex").WriteTo定期导出并清空，避免累积 - Go 1.21+ 对 mutex profile 做了优化，哈希表扩容更节制，老版本（
锁竞争分析真正的复杂点不在 profile 开关，而在于：竞争往往藏在间接调用链里（比如日志库、metric 上报、中间件 wrapper），光看 top 锁名很难定位到业务代码行。这时候得靠 pprof -http 查看完整调用图，再逐层点进去——别省这一步。