读占比≥90%时RWMutex吞吐可达Mutex的2–5倍，70%–85%仍有优势但要求临界区极轻，≤60%性能持平而死锁风险陡增，≤40%时Mutex耗时低20%～35%且延迟更稳。
别盲目换 sync.RWMutex，读写比低于 70% 时它大概率拖慢程序、卡死写 goroutine，不是“更细粒度就更好”，而是“读够多、写够轻、临界区够短”才值得用。
sync.RWMutex 写锁卡死的三个真实原因
它卡住不是因为“没人释放读锁”，而是因为写锁必须等所有已持有的读锁全部释放完——而这些读锁可能正卡在耗时操作里。
-
RLock()后做了 HTTP 请求、DB 查询或json.Marshal()，导致该读 goroutine 长时间不调RUnlock()，所有写请求全堵在runtime.gopark - 写请求排队期间，新来的读请求仍能抢到
readerSem，形成“读等写、写等读”的隐性循环，pprof/goroutine里只看到一堆sync.runtime_SemacquireMutex - 大量短生命周期读 goroutine 持续抢占 readerSem，写 goroutine 长期得不到唤醒（这不是典型写饥饿，而是读侧资源争抢反向压制）
读写比多少才该切 RWMutex？看实测，不看理论
性能拐点非常陡峭，不是线性过渡：
- 读 ≥ 90%：吞吐可达
sync.Mutex的 2–5 倍，适合配置拉取、监控指标批量Load() - 读 70%–85%：仍有优势，但要求读临界区极轻——只做
map[key]查找，不能含任何 IO 或序列化 - 读 ≤ 60%：性能基本持平，但死锁风险陡增；≤ 40% 时
sync.Mutex耗时低 20%～35%，延迟更稳
RLock() 里调 Lock() 必死锁，且 defer 救不了
Go 的 sync.RWMutex 不支持读锁升级。下面这段代码会永远卡住：
立即学习“go语言免费学习笔记（深入）”；
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()
}
}
正确做法是显式 c.mu.RUnlock() 后再 c.mu.Lock()，或者改用 double-check + 独立临界区。注意：defer 无法挽救这种结构。
比锁类型更重要的是锁粒度和替代方案
很多人换了 sync.RWMutex 没提速，问题不在锁本身，而在临界区太大——比如把整个 map 遍历包进 RLock()，并发读毫无意义。
- 只读/只写一个
int64？直接用atomic.LoadInt64/atomic.AddInt64，比RWMutex快 10 倍以上 - 写极少、读极频（如热配置）？用
atomic.Value配合不可变结构体，实现无锁读 - 数据生命周期短（单次 HTTP 请求内）？优先用
chan传递所有权，而非共享内存加锁
真正容易被忽略的，是写操作占比和临界区耗时这两个硬指标——它们决定了你面对的到底是锁竞争，还是锁误用。
