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 的写锁必须等**所有已持有的读锁释放后**才能获取。如果某个 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 的性能陷阱几乎全来自临界区内容失控，而非锁本身。