一眼识别锁竞争的关键信号是：程序无panic、cpu使用率低、http接口p99延迟突然飙升至数百毫秒或秒级、goroutine数持续上涨，且pprof goroutine堆栈大量停在(mutex).lock或(rwmutex).rlock调用上。
怎么一眼识别是锁竞争，不是卡顿或CPU打满
程序没 panic、CPU 使用率低、HTTP 接口 P99 延迟突然跳到几百毫秒甚至秒级、goroutine 数持续上涨——这大概率是锁竞争。它不报错，也不占 CPU，只是让 goroutine 在 sync.runtime_SemacquireMutex 上排队等锁。
关键验证动作：访问 http://localhost:6060/debug/pprof/goroutine?debug=2，搜 Lock 或 RLock，如果大量堆栈停在 (*Mutex).Lock 或 (*RWMutex).RLock，且调用链里没有明显 IO 或 sleep，基本可以锁定。
注意：fatal error: all goroutines are asleep - deadlock! 是真死锁，和锁竞争无关；后者是“很多人抢一把锁”，前者是“一把锁没人放，也没人能拿”。
pprof mutex profile 怎么看才不误导
运行 go tool pprof -http=:8080 http://localhost:6060/debug/pprof/mutex 后，火焰图顶部大片红色 ≠ 问题一定出在那行 Lock() 调用本身——它标的是“阻塞起点”，不是“耗时源头”。
真正要盯的两个指标：
-
flat高 +cum也高 → 锁持有时间长，大概率临界区里干了重活（比如json.Marshal()、time.Now()、http.Get()） -
flat低 +cum高 → 锁本身很快，但调用链深、竞争激烈，可能是热点路径上锁粒度太粗
必须开启高采样率才能抓到轻量竞争：runtime.SetMutexProfileFraction(1)（仅调试用），默认 1/1000 容易漏掉低频但关键的争抢。
为什么加了 sync.RWMutex 反而更慢
RWMutex 不是 Mutex 的性能升级版，它是为“读多写少 + 读操作无副作用”定制的。一旦写操作占比超过 10%，或单次读操作耗时 >100µs（比如含 fmt.Sprintf() 或 map 查找逻辑复杂），RWMutex 的原子计数开销和写锁等待所有读锁释放的机制，反而比直接用 Mutex 更拖累吞吐。
常见踩坑点：
-
RLock()后忘记RUnlock()→ 程序不会 panic，但后续所有Lock()永远阻塞 - 在
RLock()保护的临界区内调用可能触发写操作的函数（比如带缓存更新的 getter）→ 行为不可预测 - 试图从
RLock()“升级”为Lock()→ Go 不支持，直接死锁
竞态检测器（-race）为什么有时不报错
go run -race 是运行时插桩，只检测**实际执行到的并发路径**。压测没跑满、冷分支没触发、goroutine 启动后立刻退出、或者只在特定负载下才并发读写的逻辑，-race 都会沉默。
实操建议：
- 测试必须显式并发：用
sync.WaitGroup控制至少 2 个 goroutine 同时读写共享变量，不能只起 goroutine 就 return - 本地开发阶段就加
-race，别等上线靠日志猜；但绝对禁止在生产环境启用（性能降 2–5 倍，内存翻倍） - 报告里重点看
Previous write at和Current read at的行号，那是两个 goroutine 碰同一块内存的铁证
最常被忽略的一点：锁竞争本身不会触发 -race 报告——它检测的是数据竞争（data race），不是锁争用（mutex contention）。两者现象相似，根源不同，排查工具也得换。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
