锁竞争让 Go 服务变慢时看哪张图：block profile 与 mutex profile 的使用边界

Go 服务突然变慢时，如果 CPU 并没有打满，优先怀疑 goroutine 在同步点附近等待。但“等待在哪里”和“哪段临界区让别人等”不是同一个问题：前者看 block profile，后者看 mutex profile。两张图一起采集，才能把现象和责任代码接上。

判断口诀是：看到 goroutine 卡在锁、通道或 WaitGroup 上，先看 block；确认是互斥锁竞争，再看 mutex。block 的栈更接近等待动作，mutex 的栈更接近造成竞争的临界区结束位置。

先分清 block profile 和 mutex profile 记录的对象

block profile 记录 goroutine 在同步原语上花费的阻塞时间，范围包括 sync.Mutex、sync.RWMutex、sync.WaitGroup、sync.Cond 以及通道收发和 select。它回答“谁在等、等在哪里”。

mutex profile 只针对互斥锁竞争。它的栈对应造成竞争的临界区结束位置：例如一段代码持有 sync.Mutex 太久，其他 goroutine 排队，画像可能把线索落在最终解锁的路径上。因此 mutex 栈不等于等待方的栈，不能把两个结果混读。

用最小配置打开两类采样

两类画像默认都不是“打开就有”。在测试或受控实例启动时配置采样开关：

package main

import "runtime"

func enableContentionProfiles() {
	runtime.SetBlockProfileRate(1_000_000) // 平均每 1ms 阻塞时间采一个事件
	runtime.SetMutexProfileFraction(5)    // 平均报告约 1/5 的竞争事件
}

SetBlockProfileRate 的单位是阻塞纳秒，传入 1 会尽量记录每个阻塞事件，传入小于等于 0 会关闭；SetMutexProfileFraction 传入 5 表示平均每 5 个竞争事件报告 1 个，传入 0 关闭。采样值不是精确计数，比较优化前后时要保持配置和压测窗口一致。

从 pprof 输出回到共享同步点

服务已经挂载 net/http/pprof 后，可以分别抓取两个端点。若只想看一段窗口，block 和 mutex 支持 seconds=N 返回增量画像：

go tool pprof http://127.0.0.1:6060/debug/pprof/block?seconds=30
go tool pprof http://127.0.0.1:6060/debug/pprof/mutex?seconds=30

进入 pprof 后先执行 top 看累计阻塞或竞争集中在哪些函数，再用 list loadConfig 查看源码行；若要看调用关系，可使用 web。假设 serve 调用 loadConfig，共享锁名为 cacheMu：block 结果落在 cacheMu.Lock，说明等待方在排队；mutex 结果落在持锁路径的解锁侧，则应检查临界区是否把配置解析、日志或 I/O 一并包进去了。

用交叉证据决定优化方向

不要看到 mutex 热点就立刻把锁换成无锁结构。先做三次对照：第一，确认 block 热点是否与 mutex 热点属于同一把锁；第二，检查临界区是否包含可移出的计算、序列化或 I/O；第三，在相同流量和窗口重新采集，观察等待时间与吞吐是否同步改善。

如果 block 很高但 mutex 不突出，原因可能是通道、WaitGroup 或 RWMutex 读写等待，应沿 block 栈排查同步关系；如果 mutex 明显而 CPU 不高，优先缩短临界区、降低共享频率或拆分锁保护范围。-race 用于发现数据竞争，不能替代这两类画像的锁竞争定位。

相关问题

block profile 默认会记录吗？

不会。需要在程序中调用 runtime.SetBlockProfileRate，或使用测试框架提供的 block profile 选项。

生产环境可以一直打开吗？

应先在相近负载下测量开销，再按实例和时间窗口采集。官方诊断文档建议一次只收集一种画像，避免工具相互干扰。

为什么 mutex 的栈不像等待 goroutine？

mutex profile 描述的是导致竞争的临界区结束位置，等待方的直接阻塞位置应回到 block profile 对照。

小结：block 负责回答“谁在等”，mutex 负责回答“谁让锁产生竞争”。先分语义，再统一采样率和窗口，最后用 top、list 回到真实同步点，排障结论才不会偏。