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%的场景下，使用RWMutex的系统吞吐量，可能比直接用Mutex还要低20%到40%。这个数字，足以让任何性能敏感的开发者重新思考锁的选择。
- 所以，别在那些写操作预期会比较频繁的结构体上，盲目地把
Mutex替换成RWMutex。 - 善用
go tool pprof工具，观察sync.runtime_SemacquireMutex的调用热点，确认性能瓶颈是否真的源于读写锁竞争。 - 如果写操作本身就很耗时（比如涉及IO或复杂计算），那么首要任务应该是优化写逻辑本身，而不是简单地换一把锁。
读锁持有时间过长，会卡住所有写操作
RWMutex有一个严格的规则：写锁必须等待所有已持有的读锁释放后，才能成功获取。这意味着，如果某个goroutine在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 饥饿不是理论风险，而是真实发生的问题
goroutine饥饿在RWMutex的使用中并非小概率事件。它的设计默认偏向于写锁的公平性：一旦有写请求在等待队列中，新到达的读请求就会被立即阻塞。但如果写操作本身执行缓慢，或者写goroutine不幸被调度器延迟执行，就可能陷入“读操作等写锁，写操作又等读锁释放”的循环等待僵局。
还有一种更隐蔽的情况：大量短生命周期的读goroutine可能持续抢占readerSem信号量，导致等待中的写goroutine始终无法被唤醒——这可以看作是“读饥饿”的一种反向表现。
- 需要警惕这种状况。建议监控
runtime.NumGoroutine()的数量变化，并结合pprof工具观察goroutine的状态，看看是否有大量因semacquire而阻塞的实例。 - 在生产环境中，谨慎使用
TryRLock()配合循环重试的策略，它很可能加剧CPU的无谓占用和调度器的抖动。 - 对于高SLA要求的场景，一个稳妥的建议是对写路径实施熔断或限流机制，避免单个缓慢的写操作波及全局，导致服务雪崩。
说到底，并发编程中最棘手的部分，从来不是“如何加锁”这个动作本身，而是“锁里到底该放什么”。RWMutex的绝大多数性能陷阱，根源几乎都来自临界区内的内容失控，而非锁机制的设计缺陷。理解这一点，或许比选择哪把锁更重要。
