go mutex contention 是指 goroutine 因争夺 sync.mutex 或 sync.rwmutex 而阻塞等待的现象，表现为 p99 延迟飙升、goroutine 数持续增长、pprof mutex profile 显示大量红色阻塞时间且热点集中于 lock 调用。
Go mutex contention 是什么，怎么一眼识别
它不是 panic，也不是 CPU 占满，而是程序明明没做多少事，却卡在某个地方不动——比如 HTTP 接口 P99 延迟突然飙升、goroutine 数持续上涨、runtime/pprof 里 mutex profile 显示大量阻塞时间。这时候不是代码慢，是锁在排队。
关键信号：go tool pprof -http=:8080 http://localhost:6060/debug/pprof/mutex 打开后，火焰图顶部出现大片红色（代表阻塞时间），且热点集中在某个 sync.Mutex 或 sync.RWMutex 的 Lock 调用上。
怎么抓到具体哪行代码在抢锁
必须开启 mutex profiling，且采样率不能太低（默认是 1/1000，对轻量竞争不够敏感）：
- 启动时加环境变量：
GODEBUG=mutexprofilefraction=1（设为 1 表示每次 Lock 都记录，仅用于定位，上线禁用） - 或代码中显式启用：
runtime.SetMutexProfileFraction(1)，建议只在 debug 模式下生效 - 访问
/debug/pprof/mutex下载原始 profile，用go tool pprof分析，重点看「flat」列和「cum」列是否都高——说明锁本身耗时长，而非只是调用链深 - 点进具体函数后，pprof 会显示 source line，但注意：它标的是
Lock()调用行，不是临界区入口；真正问题往往在临界区里做了不该做的事（比如 IO、GC 触发、长循环）
常见锁滥用模式和替换方案
很多 contention 不是锁不够快，而是用错了场景：
立即学习“go语言免费学习笔记（深入）”；
-
sync.Map不是万能替代：它适合读多写少、key 固定的场景；如果频繁Delete或遍历，反而比加锁 map 更慢，且不支持原子 CAS - 把
time.Now()、fmt.Sprintf()、json.Marshal()放进mu.Lock()里 —— 这些操作可能触发 GC 或系统调用，直接拉长持有时间 - 用
sync.RWMutex时写锁没释放就又去读：RWMutex 不保证写锁释放后读锁立刻获得，多个 goroutine 竞争下仍可能排队 - 误以为 “小结构体不用锁”：哪怕只改一个
int64，在非 64 位对齐或跨 CPU cache line 时，仍需原子操作或锁保护；别靠直觉，用-race检测
线上环境怎么安全地查，又不拖垮服务
生产环境不能开全量 mutex profile，但也不能完全放弃监控：
- 用低频采样：
runtime.SetMutexProfileFraction(100)（默认值），配合定期 curl/debug/pprof/mutex?debug=1抓快照，观察趋势而非单次结果 - 结合
go tool trace：启动时加-trace=trace.out，打开后筛选 “Synchronization” 类别，能看到每个 goroutine 在哪个时刻被 mutex 阻塞、等了多久、谁先持有的 - 避免在高 QPS 接口里嵌入锁统计逻辑（比如每次 Lock 都打 log 或发 metric），这本身就会引入新 contention
- 如果发现某个
sync.Mutex字段名是mu或lock，但所在 struct 被高频传递（比如作为 handler 参数），大概率是锁粒度太粗——考虑拆成 per-key 锁或用sync.Pool缓存带锁对象
锁竞争的本质不是“有没有锁”，是“谁在等、等多久、为什么等”。profile 只给现象，真正要动手的，永远是临界区里的那几行代码。
