RWMutex在读多写少场景下更快，因其允许多读并发但写独占；读超70%时吞吐可提升2–5倍，但需确保读不修改状态、不混用锁、不升级锁，且须防范死锁与写饥饿。
为什么 RWMutex 在读多写少场景下比 Mutex 更快
因为 RWMutex 允许多个 goroutine 同时读，但写操作会独占；而 Mutex 无论读写都串行。当读操作占比超过 70%，RWMutex 的吞吐量通常能提升 2–5 倍——前提是读操作本身不修改共享状态。
关键限制在于：一旦有 goroutine 调用 RWMutex.Lock()（写锁），所有后续的 RWMutex.RLock()（读锁）都会阻塞，直到写锁释放。这不是“读优先”或“写优先”的调度问题，而是 Go 标准库实现的公平性策略：写锁请求到达后，新来的读锁会被排队等待。
- 读操作必须只调用
RWMutex.RLock()和RWMutex.RUnlock() - 写操作必须用
RWMutex.Lock()/RWMutex.Unlock()，不能混用RUnlock() - 不能在持有读锁时尝试升级为写锁——Go 不支持锁升级，会死锁
RWMutex 死锁的典型触发方式
最常见的是在持有 RWMutex.RLock() 的 goroutine 中，又去调用 RWMutex.Lock()。例如缓存查找失败后想顺手写入，却忘了先释放读锁。
mu.RLock()
if val, ok := cache[key]; ok {
mu.RUnlock() // ✅ 必须先放掉读锁
return val
}
mu.RUnlock() // ✅ 这里也要确保释放
mu.Lock() // ✅ 再拿写锁
cache[key] = compute(key)
mu.Unlock()
另一个隐蔽坑：defer 在读锁作用域内注册了 mu.RUnlock()，但中间又调用了可能 panic 的函数，导致 defer 没执行完就进入写锁逻辑——结果是读锁未释放 + 写锁阻塞，整个结构卡死。
立即学习“go语言免费学习笔记（深入）”；
- 不要 defer
RUnlock()在可能跨锁类型的函数中 - 避免在
RLock()后直接调用不可信的第三方函数 - 用
go vet检查不到锁匹配问题，需靠代码审查或单元测试覆盖读写混合路径
什么时候不该用 RWMutex
当读操作本身很重（比如遍历大 map + 序列化成 JSON），或者写操作非常频繁（写占比 > 30%），RWMutex 反而比 Mutex 更慢。原因在于读锁的获取/释放也有开销，且写锁饥饿风险上升。
更麻烦的是：如果读操作里隐式触发了写（比如日志埋点修改了某个计数器），那就不是纯读——RWMutex 的语义被破坏，数据竞争检测工具（go run -race）可能报错，而运行时未必崩溃。
- 检查所有
RLock()区域内的函数调用链，确认无副作用写入 - 对小结构体（如几个字段的 config）直接用
sync/atomic或只读拷贝，比加锁更轻量 - 高并发写场景下，考虑分片锁（sharded mutex）或
sync.Map（仅适用于 key-value 场景）
如何验证 RWMutex 真正生效了
光看代码不能确定优化有效。得用 go tool trace 或 pprof 观察 goroutine 阻塞时间和锁竞争热点。
简单验证法：在读密集路径加计时，对比切换 Mutex 和 RWMutex 后的 QPS 和 p99 延迟。注意控制变量——比如禁用 GC、固定 GOMAXPROCS、使用相同压测工具和数据集。
- 用
runtime.SetMutexProfileFraction(1)开启锁竞争采样（仅开发/测试环境） -
go tool pprof -http=:8080 mutex.profile查看哪些函数在争抢同一把锁 - 若 trace 中显示大量 goroutine 卡在
sync.(*RWMutex).RLock，说明写锁持有时间过长，不是读锁的问题，而是写操作太重
真正难调的是读写比例动态变化的场景——比如高峰期写变多，RWMutex 自动退化成瓶颈。这种时候，锁策略得配合业务节奏做切换，而不是一劳永逸。
