需在程序启动时调用 runtime.setmutexprofilefraction(n)（n>0）开启 mutex profile，否则 /debug/pprof/mutex 为空；n=1 记录每次竞争，n=5 约每5次采样一次，仅影响后续锁操作。
怎么开启 go 的 mutex profile
Go 自带的 runtime/pprof 支持采集 mutex 争用信息，但默认关闭——不是没数据，是根本没开采集开关。
- 必须在程序启动时设置
runtime.SetMutexProfileFraction(1)（或大于 0 的值），否则mutexprofile 始终为空 - 设为 1 表示记录每一次锁竞争；设为 5 则约每 5 次记录一次，适合高并发场景降噪
- 注意：该设置只影响后续发生的锁竞争，已持有的锁、已释放的锁不回溯
- 如果用
net/http/pprof，需确保服务启动前已调用该函数，否则 /debug/pprof/mutex 返回 “no mutex profile data”
mutex profile 输出里怎么看真实耗时
profile 文件本身不直接显示“某次加锁花了多少毫秒”，而是统计「阻塞在锁上」的总时间（即 goroutine 等待获取锁的累计时长）和调用栈频次。
- 关键字段是
Duration（单位 ns），它表示所有 goroutine 在该锁位置等待的总时间，不是单次延迟 - 真正反映“慢”的是
Flat时间占比高的栈——比如某个sync.Mutex.Lock()调用点占了总 mutex 阻塞时间的 70% - 别被
Cum值误导：它包含下游调用链的阻塞时间，可能掩盖真正卡点；优先看Flat+samples - 示例中看到
runtime.semacquire1占比高，说明不是业务逻辑慢，而是锁确实抢得激烈
为什么 pprof top 含糊、graph 看不出问题
mutex profile 的调用栈深度常被截断，且默认聚合策略容易隐藏根因。
-
pprof -top默认只显示前 10 行，而真正耗时的锁可能排在第 12 或第 18 —— 加-n 50才能看清全貌 -
pprof -graph会把不同锁合并成同一节点（只要底层都走sync.Mutex.Lock），导致看不出是哪个具体字段/结构体在争用 - 解决办法：用
go tool pprof -lines mutex.pprof强制展开到源码行级；再配合-focus=YourStruct.Lock过滤特定锁实例 - 若多个
sync.Mutex字段共用同一个类型名（如都叫mu sync.Mutex），pprof 无法区分——得靠命名差异（如cacheMu,stateMu）才能准确定位
生产环境采样要不要开 full profile
开全量（SetMutexProfileFraction(1)）对性能有可测影响，尤其在锁极频繁的服务中。
立即学习“go语言免费学习笔记（深入）”；
- 实测：QPS 5k+ 的 HTTP 服务，开启后 CPU 使用率上升 8%~12%，GC 压力略增
- 建议分阶段：先用
5或10快速定位热点锁；确认问题后再临时切到1抓细粒度数据 - 不要长期开着；更别在压测中途动态修改该值——会导致 profile 数据混杂，统计失真
- 如果发现
runtime.futex或runtime.usleep出现在栈顶，说明已进入系统调用等待，这时光看 mutex profile 不够，得结合 trace 分析调度延迟
实际跑起来你会发现，最麻烦的往往不是看不懂 profile，而是锁分布在几十个包里、名字都叫 mu，又没有注释说明保护什么——这时候得靠 go list -f '{{.Deps}}' . 搭配 grep 锁变量名，一层层翻源码。