runtime.SetMutexProfileFraction 是控制 Go 互斥锁争用采样的函数，需在程序启动时调用正整数 n（如 1 或 5）以开启采集，设为 0 则关闭；它仅影响后续锁竞争，且只对 sync.Mutex 和 sync.RWMutex 生效。
runtime.SetMutexProfileFraction 是什么，什么时候该调用
runtime.SetMutexProfileFraction 控制运行时是否采集互斥锁（sync.Mutex 和 sync.RWMutex）的争用事件。它不是“开启/关闭”开关，而是采样率控制：传入正整数 n 表示平均每 n 次锁竞争中记录 1 次；传 0 表示完全关闭（默认值）；传 1 表示全量采集（不推荐生产环境）。
它只对后续发生的锁竞争生效，不影响已存在的 goroutine 或已持有的锁。典型使用场景是：怀疑存在锁瓶颈、想定位哪段代码频繁抢锁、或验证锁粒度是否合理。
- 开发/测试阶段可设为
1快速复现问题 - 压测中建议设为
5或10，平衡精度与开销 - 线上诊断务必避免设为
1—— 全量采集会显著拖慢吞吐，尤其高并发服务
如何获取并解析 mutex profile 数据
Go 的 mutex profile 不通过 pprof HTTP 接口直接暴露，必须手动触发写入。调用 runtime.SetMutexProfileFraction 后，需在程序退出前或特定时机调用 pprof.Lookup("mutex").WriteTo 输出原始数据。
示例片段：
import (
"net/http"
_ "net/http/pprof"
"os"
"runtime/pprof"
)
func main() {
runtime.SetMutexProfileFraction(5) // 开始采样
// ... 业务逻辑
f, _ := os.Create("mutex.pprof")
pprof.Lookup("mutex").WriteTo(f, 0)
f.Close()
}
生成的 mutex.pprof 文件不能直接阅读，需用 go tool pprof 分析：
-
go tool pprof -http=:8080 mutex.pprof启动 Web 界面，查看火焰图和调用树 -
go tool pprof -top mutex.pprof查看争用最频繁的函数栈 - 注意：输出中 “flat” 列是该函数自身触发争用的次数，“cum” 是包含其调用链的累计次数
常见误判：为什么 profile 显示争用多，但实际没卡顿
mutex profile 记录的是“成功抢到锁前等待的次数”，不是“阻塞时间”。一次毫秒级等待和一次秒级等待，在默认采样下都只计为 1 次。所以高频率低延迟的争用（如热点计数器）可能刷屏，但对性能影响小；而低频但长等待（如锁内做了 I/O）反而容易被漏掉或低估。
- profile 中出现大量
sync.(*Mutex).Lock调用，要顺藤摸瓜看它的持有者 —— 真正耗时的是锁保护的那段代码，不是Lock本身 - 若
pprof.Lookup("mutex").WriteTo输出为空，检查是否调用过runtime.SetMutexProfileFraction，且之后确实发生了竞争（仅 Lock 不触发，必须有 goroutine 等待） - goroutine 在等待锁时若被抢占或调度，profile 仍会计数，但无法反映真实延迟 —— 这时候需要结合
go tool trace看调度延迟
和 GODEBUG=mcs=1 的区别在哪
GODEBUG=mcs=1 是编译期/运行期调试标志，启用后会在每次锁竞争时打印日志到 stderr，格式为 lock contention on <addr> by goroutine <n>。它和 runtime.SetMutexProfileFraction 完全无关，也不受其控制。
-
mcs=1是粗粒度、无上下文、不可过滤的日志轰炸，仅适合单次调试、极简复现场景 -
SetMutexProfileFraction+pprof提供可采样、可聚合、带完整调用栈的分析能力，适合定位根因 - 两者可同时启用，但
mcs=1日志量极大，切勿在线上开启
真正难的不是采集数据，而是区分“高频短等”和“低频长等”——profile 本身不带时间戳，得靠你结合业务逻辑判断哪类争用值得优化。
