Go mutex profile 没有热点时怎么确认采集开关

排查 Go 服务的锁竞争时，如果 go tool pprof 里没有 mutex 热点，第一步不是立刻改锁，而是确认采集开关。Go 的 mutex profile 默认不启用；可以用 runtime.SetMutexProfileFraction(-1) 读取当前比例，返回 0 就说明没有采集。即使开关已打开，也要等真实竞争发生，并从同一个进程读取 profile。

没有 mutex 热点通常只有四种解释：采集关闭、采样太稀疏、采样窗口内没有竞争，或者 pprof 读到的不是产生竞争的进程。

先确认 mutex profile 的采集开关

把“有没有热点”拆成两个问题：当前进程是否采集，以及采集期间是否真的发生过竞争。下面的检查函数不会改变开关，只读取运行时状态：

package main

import (
    "fmt"
    "runtime"
)

func main() {
    // 负数只读取当前采样比例，不会修改运行时配置。
    rate := runtime.SetMutexProfileFraction(-1)
    fmt.Printf("mutex profile rate=%d\n", rate)
}

返回值为 0 时，先在排查窗口启用采集；返回正数才说明开关处于打开状态。比例为 1 表示平均每个竞争事件都参与记录，比例更大的数会降低采样密度，适合把短时排查对生产开销控制得更谨慎。

采样比例要和排查窗口一起设置

临时排查时可以保存旧值，打开采集，完成一段有代表性的压测或请求后恢复。恢复动作很重要，否则长期开启可能增加不必要的运行时记录成本：

old := runtime.SetMutexProfileFraction(1)
defer func() {
    // 排查结束后恢复调用前的设置，避免影响后续流量。
    runtime.SetMutexProfileFraction(old)
}()

// 这里应放一段能稳定复现锁竞争的业务请求或压测窗口。
runContentionWindow()

不要刚启动服务就马上读取。采样是事件驱动的，窗口内没有竞争，profile 为空是正常结果；窗口太短或比例太低，也可能只留下很少记录。建议把“启用时间、产生竞争的请求区间、读取时间”作为一次排查的三个标记。

为什么热点常常落在 Unlock 附近

mutex profile 的语义不是“哪个函数调用 Lock 最多”，而是记录互斥锁竞争导致的等待代价。一个 goroutine 持锁执行临界区时，其他 goroutine 可能在等待；当锁最终释放，采样栈通常归到临界区结束位置，也就是 sync.Mutex.Unlock 附近。因此看到 Unlock 热点，不等于 Unlock 本身耗时，真正该查的是它前面的临界区是否过长。

确认读取入口和 profile 类型

如果服务注册了 net/http/pprof，可以从同一个进程的 /debug/pprof/mutex 读取，再交给 go tool pprof 分析。也可以在程序内通过 pprof.Lookup("mutex") 获取 profile 并写出。关键是确认端口、进程和采样窗口属于同一实例。

这两个 profile 经常被混用：mutex profile 聚焦锁竞争，block profile 覆盖的同步阻塞范围更广。看到通道等待时，继续看 mutex profile 往往不会得到答案；反过来，只看 block profile 也可能掩盖具体是哪把互斥锁形成了热点。

常见问题

返回 0 就代表程序没有锁竞争吗？

不是。返回 0 只说明 mutex profile 当前关闭，不能推断业务没有竞争。

把比例设成 1 后仍然为空怎么办？

确认设置发生在目标进程，并让等待者与持锁者在同一窗口内真实重叠，再检查读取的 pprof 地址。

为什么 profile 栈顶是 Unlock？

这是 mutex profile 的归属语义，应该回看对应临界区，而不是单独优化 Unlock。

什么时候改看 block profile？

当症状是通道、WaitGroup、Cond 或其他同步原语阻塞，而不是互斥锁竞争时，使用 block profile 更合适。

排查顺序可以固定为：读取当前比例，设置受控窗口，制造并确认竞争，再读取同一进程的 mutex profile；只有这条链路成立，热点为空才有诊断意义。