RWMutex仅在读占比≥90%时吞吐达Mutex的2–5倍，70%–85%需临界区极轻，≤60%性能持平但死锁风险陡增，≤40%时Mutex耗时低20%～35%且更稳定。
读写比低于 70% 时，RWMutex 很可能拖慢程序
别因为“读写锁听起来更高级”就换。实测表明：sync.RWMutex 只在读操作占比 ≥90% 时吞吐可达 sync.Mutex 的 2–5 倍；70%–85% 区间仍有优势，但要求临界区极轻——只做 map[key] 查找，不能含任何 IO、JSON 序列化或 DB 查询；一旦读占比 ≤60%，性能基本持平，死锁风险却陡增；≤40% 时 sync.Mutex 反而耗时低 20%～35%，延迟更稳。
常见误判场景：
- 以为“缓存读多”就适合 RWMutex，结果
RLock()后顺手调了log.Printf()（内部带锁）或更新了lastAccess字段（隐式写） - 压测报告里读请求 QPS 高，但没拆解单次读的耗时——如果一次
RLock()包了 HTTP 调用 + 解析 JSON，那它根本不是“读”，而是“伪读” - 用
go tool trace看到大量runtime.futex占比 >10%，实际是 goroutine 在等锁，而持有者卡在 IO 上，和锁类型无关
RLock() 里调 Lock() 必死锁，defer 救不了
sync.RWMutex 不支持读锁升级。下面这段代码会永远卡住：
func (c *Counter) IncrementIfZero() {
c.mu.RLock()
defer c.mu.RUnlock() // ❌ defer 在函数返回才执行，但下一行已死锁
if c.value == 0 {
c.mu.Lock() // ⚠️ 等待自己释放 RLock
c.value++
c.mu.Unlock()
}
}
正确做法只有两种：
立即学习“go语言免费学习笔记（深入）”；
- 显式
c.mu.RUnlock()后再c.mu.Lock()，但中间存在竞态窗口（值可能被其他 goroutine 改） - 改用 double-check：先
RLock()快速判断，RUnlock()，再Lock()重查并修改
注意：defer 在这种混合锁路径中极易失效——panic、return 提前、context 取消都可能导致 RUnlock() 没执行，后续所有 Lock() 永久阻塞。
写操作占比超 15%～20%，RWMutex 反而更慢
写操作本身耗时（比如加载 YAML 配置）、或写频率高（每 100 次读就有 5 次写），sync.RWMutex 的状态切换开销（读者计数、写者排队、唤醒逻辑）就会超过 sync.Mutex 的简单互斥成本。
典型症状：
- pprof 显示
sync.runtime_SemacquireMutex大量堆积，且 goroutine 状态长期为semacquire - 新写请求被“饿死”：已有大量短生命周期读 goroutine 持续抢占
readerSem，写 goroutine 长期得不到唤醒 - 写操作里嵌套了读逻辑（如更新后立即遍历 map 发送通知），进一步加剧锁竞争
这时换回 sync.Mutex 或改用分片锁（sharded mutex）往往更有效——尤其当共享结构是 map 时，64 分片比一把锁快一个数量级。
真正容易被忽略的两个硬指标
决定你该不该用 sync.RWMutex 的，从来不是文档描述或理论模型，而是两个可测量的硬指标：
-
实际读写比：用 pprof 或自埋点统计单位时间内
RLock()和Lock()的调用次数，不是靠业务逻辑“感觉” -
临界区平均耗时：用
time.Since()包裹每个RLock()到RUnlock()区间，确认是否稳定
这两个数字不达标，再怎么调优锁逻辑也没用——问题不在锁本身，而在临界区干了不该干的事。
