RWMutex在读多写少时性能优于Mutex，但写频繁或读锁持有时间长时反而更慢且易引发goroutine饥饿；其内部状态复杂、读写竞争加剧调度开销，写占比超30%时吞吐量可能低20%～40%。
读多写少时 RWMutex 性能明显优于 Mutex；但一旦写操作变多或读锁持有时间过长，它反而比 Mutex 更慢，且容易引发 goroutine 饥饿。
写操作频繁时，RWMutex 会比 Mutex 还慢
因为 RWMutex 内部状态更复杂：它要维护 readerCount、readerWait、两个信号量和一个嵌套的 Mutex。每次 RLock() 和 RUnlock() 都需原子操作+条件判断，而 Mutex 的 Lock()/Unlock() 是更轻量的 CAS 操作。
当写请求密集出现时，RWMutex 会主动阻塞新来的读请求（防止写饥饿），导致读 goroutine 大量排队，调度开销上升。实测中，在写占比超 30% 的场景下，吞吐量可能比用 Mutex 低 20%～40%。
- 不要在写操作预期较频繁的结构体上盲目替换
Mutex为RWMutex - 用
go tool pprof观察sync.runtime_SemacquireMutex调用热点，确认是否真由读写锁竞争引起延迟 - 若写操作本身耗时较长（比如涉及 IO 或计算），应优先优化写逻辑，而不是换锁
读锁持有时间过长，会卡住所有写操作
RWMutex 的写锁必须等**所有已持有的读锁释放后**才能获取。如果某个 RLock() 后做了耗时操作（如 HTTP 请求、数据库查询、大数组遍历），后续所有 Lock() 都会被挂起，甚至拖垮整个服务。
典型错误模式：
func getValue(key string) string {
rwmu.RLock()
// ❌ 危险：网络调用不能放在锁内
resp, _ := http.Get("https://api.example.com/" + key)
defer resp.Body.Close()
data, _ := io.ReadAll(resp.Body)
rwmu.RUnlock()
return string(data)
}
- 读锁临界区只应包含内存访问，避免任何阻塞或 IO
- 若读取逻辑必须含 IO，考虑提前复制数据、用缓存或改用 channel 分离读写路径
-
RWMutex不支持锁升级，别试图在RLock()后再调Lock()—— 会死锁
goroutine 饥饿不是理论风险，而是真实发生的问题
RWMutex 默认偏向写锁公平性：一旦有写请求在等待，新进的读请求就会被阻塞。但如果写操作本身也慢，或者写 goroutine 被调度器延迟，就可能出现“读等写、写等读”的循环等待。
更隐蔽的是：大量短生命周期读 goroutine 可能持续抢占 readerSem，让写 goroutine 始终无法唤醒 —— 这就是读饥饿（read starvation）的反向表现。
- 监控
runtime.NumGoroutine()和 pprof 中 goroutine 状态，看是否有大量semacquire阻塞 - 生产环境慎用
TryRLock()循环重试，它可能加剧 CPU 占用和调度抖动 - 高 SLA 场景建议对写路径做熔断或限流，避免单个慢写拖垮全局
真正难处理的从来不是锁怎么加，而是锁里该放什么 —— RWMutex 的性能陷阱几乎全来自临界区内容失控，而非锁本身。
