Go mutex profile 默认只记录锁持有时间而非等待时间，需调用 runtime.SetMutexProfileFraction(n)（n为正整数）开启等待采样，且仅对 sync.Mutex/RWMutex 生效。
Go mutex profile 为什么默认看不到锁等待时间
Go 的 runtime/pprof 默认开启的 MutexProfile 实际上只记录「持有锁的时间」，不是你关心的「线程在 WaitQueue 里干等了多久」。要看到真正的竞争等待，必须显式开启采样且设置足够低的阈值，否则大部分短等待直接被过滤掉。
-
runtime.SetMutexProfileFraction(n)必须设为正整数（比如1），设为0或未调用就等于关闭等待统计 - 这个值不是「采样率」，而是「平均每 n 纳秒的锁等待才记录一次」；设太小（如
1）会拖慢程序，设太大（如1000000）可能漏掉关键等待 - 只对
sync.Mutex和sync.RWMutex生效，channel或自定义锁不计入
怎么拿到真实的锁等待堆栈（含 goroutine 调用链）
光开 SetMutexProfileFraction 不够，你还得从 pprof 接口导出并用正确方式查看——直接看文本输出容易误读「谁在等」和「谁在占」。
- 启动时加
http.ListenAndServe("localhost:6060", nil)，然后访问http://localhost:6060/debug/pprof/mutex?debug=1 - 返回内容里每段以
--- mutex:开头的是一个等待事件，下面的 stack trace 是「等待者」的调用栈，不是持有者 - 持有者信息藏在
sync.(*Mutex).Lock上方最近那个非 runtime 的函数里，需要手动向上翻两到三行定位 - 如果看到大量
runtime.semawakeup或runtime.notetsleepg在栈顶，说明等待已进入系统级休眠，这时延迟通常 >10ms，问题比较严重
profile 数据不准的三个典型原因
很多人跑出来发现「没数据」或「数据和预期不符」，基本逃不出这三种情况。
- 程序运行时间太短：Mutex profile 是累积统计，进程生命周期内没发生够多的锁竞争，
debug=1输出可能为空或只有几行 - 锁被快速释放：比如
mu.Lock(); defer mu.Unlock()包裹的只是几个赋值，等待时间远低于SetMutexProfileFraction设置的阈值，直接被丢弃 - 用了
sync.Pool或复用对象：同一个sync.Mutex实例被反复 Reset/重用，pprof 会把不同逻辑路径的等待混在一起，看不出真实业务上下文
生产环境要不要开 MutexProfile
能不开就不开。它带来的开销比 CPU 或 heap profile 高得多，尤其在高并发抢锁场景下，可能让 P99 延迟跳升一个数量级。
立即学习“go语言免费学习笔记（深入）”；
- 临时诊断可以开，但务必控制时长（比如只开 30 秒，用完立刻设回
0） - 不要长期写死
SetMutexProfileFraction(1)在 main.init 里 - 如果必须持续观察，建议改用
go tool trace配合runtime/trace，它能捕获更细粒度的阻塞事件，且开销可控
锁等待时间不是越细越好，关键是确认瓶颈是否真在锁上——有时候 goroutine 泄漏或 GC 停顿也会伪装成锁等待，别急着优化 mu.Lock()。
