RWMutex适用于读远多于写的场景，允许多读单写以提升并发读吞吐，但写频繁时易致writer饥饿或性能下降；需严格配对RLock/RUnlock，避免死锁与panic。
为什么读多写少时不能只用Mutex
因为 Mutex 是完全互斥的：哪怕只是并发读，也会被串行化。在高并发读场景下，大量 goroutine 会排队等锁，吞吐量直接掉下来。而 RWMutex 允许多个 reader 同时持有读锁，只有 writer 需要独占——这是它存在的根本理由。
但要注意：RWMutex 不是银弹。它的内部实现比 Mutex 复杂，读锁也有开销；如果写操作频繁（比如每秒几百次），反而可能因 writer 饥饿或锁竞争加剧而更慢。
Read/Write 锁的正确配对使用方式
必须严格区分读写路径，且读写锁调用必须成对出现，否则会导致 panic 或死锁。常见错误包括：
- 忘记调用
RUnlock()，尤其在 error early return 分支里 - 在持有读锁期间调用
Lock()—— 这会死锁（Go runtime 不检查） - 误把
RLock()当作可重入锁，在嵌套函数中重复调用
推荐写法：用 defer mu.RUnlock() 确保释放，哪怕函数提前返回。
立即学习“go语言免费学习笔记（深入）”；
func (c *Cache) Get(key string) (string, bool) {
c.mu.RLock()
defer c.mu.RUnlock()
v, ok := c.data[key]
return v, ok
}
func (c *Cache) Set(key, value string) {
c.mu.Lock()
defer c.mu.Unlock()
c.data[key] = value
}
RWMutex 的饥饿模式与性能陷阱
Go 1.18+ 默认启用 RWMutex 的饥饿模式（starvation），避免 writer 长期等待。但代价是：一旦有 writer 在排队，后续 reader 会直接阻塞，不再尝试获取读锁——这在突发写请求时会让读延迟陡增。
如果你的场景写操作极少（如配置加载后几乎只读），可以考虑禁用饥饿模式（需自己封装）；但绝大多数服务默认行为更安全。
- 查看是否启用饥饿：源码中
rwmutex.go的starving字段为true - 实测发现：当 writer QPS > 50，且 reader QPS > 5k 时，开启饥饿后 P99 读延迟可能上升 2–3 倍
- 没有公开 API 控制该行为，强行绕过会破坏兼容性，不建议
替代方案：什么时候该换别的同步机制
RWMutex 适合「读远多于写 + 数据结构简单 + 无复杂依赖」的场景。一旦出现以下情况，就该考虑其他方案：
- 读操作本身耗时较长（如含网络调用或大对象拷贝）——此时应改用 copy-on-write（如
sync.Map或不可变快照） - 需要条件等待（如“等某个字段变为 true”）——得上
Cond，但注意Cond必须和*Mutex配合，不能和RWMutex混用 - 数据分片明显（如按 key 哈希）——用分片
map[string]*sync.RWMutex比全局锁更高效 - 写操作带校验或依赖外部状态——可能更适合 channel + 单 goroutine 串行处理
真正难的不是选 RWMutex，而是判断「读多写少」这个前提是否稳定成立。线上压测时，务必同时观察 RWMutex 的 reader/writer 等待时间（可用 pprof mutex profile），而不是只看 CPU 或 QPS。
