sync.Mutex 和 sync.RWMutex 在什么场景下性能差异大？
先说核心结论：当读操作占比超过70%时，RWMutex的优势会非常明显；而当读操作占比低于40%时，Mutex反而更稳定、更安全。
读多写少场景下 RWMutex 吞吐高 2–5 倍
道理其实很简单。在那些读操作占绝对主导的场景里——比如缓存命中率超过90%、配置信息的只读拉取，或者监控指标的高频读取——sync.RWMutex 的 RLock() 允许一群 goroutine 同时进入临界区。这直接打破了 sync.Mutex 下所有读请求必须排队、一个接一个的瓶颈。
实测数据（Go 1.22，8核环境）很能说明问题：在90%读、10%写的负载下，RWMutex 的整体耗时大约只有 Mutex 的30%到40%。不过，这里有个至关重要的前提：临界区的操作必须极轻量级。比如，仅仅是做个 map[key] 的查找，不涉及序列化、网络调用或者大切片遍历这些耗时操作。
- 典型适用场景：HTTP处理器中，用
configMu.RLock()锁一下，然后快速读取cfg.Timeout这类配置值。 - 典型不适用场景：在持有
RLock()期间，却去调用json.Marshal或者http.Get。这会让其他所有的读锁和写锁请求全部卡住，完全违背了使用读写锁的初衷。 - 需要警惕的是：
RWMutex并非“读得越快，写得就越不慢”。它只是解开了读操作之间的互斥；写锁（Lock()）仍然必须等待所有活跃的读锁释放。所以，如果读操作本身就很耗时，写操作就会被严重拖累。
读写接近（40%–60%）时直接用 Mutex 更省心
一旦读写比例变得均衡，比如各占50%左右，情况就变了。RWMutex 因为要维护额外的状态（比如原子读取 readerCount、判断是否有写锁在等待），加上读写模式频繁切换带来的开销，其性能反而会比简单的 Mutex 略逊一筹。更重要的是，它在这个区间引入的复杂性，带来了新的死锁风险。
- 常见陷阱：那种“先读后判断，再决定是否写”的逻辑。例如
if x == 0 { mu.Lock(); x++ }。如果这里用的是RWMutex，在已经持有RLock()的情况下再去调用Lock()，程序会立刻死锁。 - Mutex的优势：它的加锁路径最短，调度行为高度可预测，没有写饥饿、读锁升级失败这些令人头疼的问题。
- 一个实用建议：一个命名清晰（比如
cacheMu）、粒度合适（不盲目锁住整个结构体）的Mutex，其实际效果往往比一个被滥用的RWMutex要好得多。
写频繁（读 ≤ 40%）时 RWMutex 反而更慢且易死锁
当写操作开始频繁时，RWMutex.Lock() 就成了性能瓶颈。它必须耐心等待所有已持有的 RLock() 释放完毕，而后续新来的读锁请求又会被这个等待中的写锁挂起排队。这就形成了一种“读写互相阻塞”的恶性循环，性能损耗会被放大。
- 实测数据：在10%读、90%写的极端场景下，
Mutex的耗时反而要低20%到35%，并且延迟更加稳定。 - 更隐蔽的死锁：此时出现的死锁可能不是传统的A等B、B等A的环路。而是“读锁未释放 → 写锁在等待 → 新的读锁在排队”这种链式阻塞，从堆栈信息里很难直接看出依赖关系。
- 此时应该考虑什么：与其纠结锁的类型，不如优先考虑无锁方案。比如用
atomic.Int64处理计数器，用atomic.Value原子交换不可变配置，或者通过chan来传递数据的所有权。
话说回来，真正决定并发程序性能的，往往不是选择 Mutex 还是 RWMutex 这个二选一的问题。关键在于：锁保护的范围是不是过大？临界区里是不是干了不该干的“重活”？以及，有没有更优雅的无锁替代方案可以选用？别让 RWMutex 成为掩盖粗粒度锁设计的一块“遮羞布”。
