RWMutex在读占比≥70%时明显更快，读≤40%时Mutex更稳安全；90%读场景下吞吐高2–5倍，但仅适用于临界区极轻的只读操作，否则易引发写饥饿与死锁。
读占比 ≥ 70% 时 RWMutex 明显更快，读占比 ≤ 40% 时 Mutex 更稳且更安全
读多写少场景下 RWMutex 吞吐高 2–5 倍
当读操作占绝对主导（比如缓存命中率 >90%、配置只读拉取、监控指标高频读取），sync.RWMutex 的 RLock() 允许多个 goroutine 并发进入，避免了 sync.Mutex 下所有读请求排队等待的瓶颈。
实测（Go 1.22，8 核）显示：90% 读 + 10% 写时，RWMutex 耗时约为 Mutex 的 30%～40%；但前提是临界区极轻——比如只做 map[key] 查找，不带序列化、网络调用或大 slice 遍历。
- 典型适用：HTTP handler 中只读配置
configMu.RLock()后取cfg.Timeout - 不适用：在
RLock()持有期间调用json.Marshal或http.Get—— 这会让其他读/写全部卡住 - 注意：
RWMutex不是“读越快写越不慢”，它只是把读并发放开了；写锁仍需等所有活跃读锁释放，所以读操作若本身耗时长，写就会被拖住
读写接近（40%–60%）时直接用 Mutex 更省心
一旦读占比掉到 50% 左右，RWMutex 因额外的状态检查（原子读取 readerCount、判断是否有等待中的写锁）、读写切换开销，反而比 Mutex 略慢。更重要的是，它引入了新的死锁风险点。
- 常见陷阱：「读→判断→写」逻辑，如
if x == 0 { mu.Lock(); x++ }—— 若用RWMutex，RLock()后再Lock()必死锁 -
Mutex加锁路径最短，调度可预测，没有写饥饿、读升级失败等问题 - 命名清晰（如
cacheMu）、粒度合适（不包整个结构体）的Mutex，往往比滥用RWMutex更高效
写频繁（读 ≤ 40%）时 RWMutex 反而更慢且易死锁
写操作一多，RWMutex.Lock() 就成瓶颈：它必须等所有已持有的 RLock() 全部释放，而新来的 RLock() 又会被挂起排队——形成“读写互相阻塞”的放大效应。
- 实测数据：10% 读 + 90% 写时，
Mutex耗时低 20%～35%，延迟也更稳定 - 死锁更隐蔽：不是 A 等 B、B 等 A 的环路，而是「读未释放 → 写在等 → 新读在排队」，堆栈看不出依赖链
- 此时应优先考虑
atomic.Int64（计数器）、atomic.Value（不可变配置）、或chan传递所有权，而非换锁类型
真正影响性能的，往往不是选 Mutex 还是 RWMutex，而是锁保护的范围是否过大、临界区是否做了不该做的事、以及有没有更无锁的替代方案。别让 RWMutex 成为掩盖粗粒度锁的遮羞布。
