Go语言中，sync.RWMutex读写冲突对性能有何具体影响？

本文共计867个文字，预计阅读时间需要4分钟。

读多写少时，使用`RWMutex`性能明显优于`Mutex`；但一旦写操作变多或读锁持有时间过长，它反而比`Mutex`更慢，且更容易引发死锁。

写操作频繁时，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 的写锁必须等**所有已持有的读锁释放后**才能获取。