RWMutex在读占比≥70%时明显更快，90%读场景下吞吐量为Mutex的2–5倍；读占比≤40%时Mutex更稳更快；40%–60%区间性能持平但RWMutex风险陡增；真正影响性能的是锁粒度而非锁类型。
读占比 ≥ 70% 时 RWMutex 明显更快
实测（Go 1.22，8 核）显示：当读操作占总访问量 90% 时，sync.RWMutex 的吞吐量约为 sync.Mutex 的 2–5 倍。典型场景包括：
- 缓存命中率高的配置读取（如
configMu.RLock()拉取只读字段） - 监控指标批量拉取（Prometheus exporter 中频繁
Load()计数器） - 静态资源元数据查询（如文件列表、schema 描述等极少更新的内容）
关键前提是：读操作本身极轻量（不调用 json.Marshal、不发 HTTP 请求、不遍历大 slice），否则 RLock() 持有时间过长，会拖累写锁获取，反而放大竞争。
读占比 ≤ 40% 时 Mutex 更稳更快
一旦写操作超过 40%，sync.RWMutex 不仅没优势，还更慢——实测 10% 读 + 90% 写时，sync.Mutex 耗时低 20%～35%。原因很直接：
-
RWMutex.Lock()必须等待所有现存RLock()全部释放，哪怕只剩 1 个 goroutine 在做耗时读操作，写就卡住 - 新来的
RLock()在写锁排队期间也会被挂起（不是“只阻塞写”，而是“写锁优先级最高”） - 每次
RLock()都要原子读取状态并判断是否有等待中的写锁，这部分开销在写频繁时成为负收益
这种场景下硬上 RWMutex，往往换来的是写饥饿和更差的 P99 延迟。
读写比例在 40%–60% 之间，别纠结锁类型
这个区间里两者性能基本持平，但 sync.RWMutex 的风险陡增：
- “读→判断→写”逻辑极易死锁（例如
if x == 0 { mu.Lock(); x++ }） - 交叉死锁更隐蔽：堆栈里看不到环路，只有
runtime.gopark卡在RWMutex.Lock或RWMutex.RLock - 调试成本远高于
sync.Mutex，因为涉及读计数器、等待队列、writerSem 等多状态协同
此时选 sync.Mutex 是更务实的选择——它路径短、行为可预测、出问题容易复现。
真正影响性能的，往往不是锁类型，而是锁粒度
很多团队换了 RWMutex 发现没提速，甚至更慢，问题通常不在锁本身：
- 用一个
mu包住整个结构体，而其中某些字段几乎不读、某些字段高频读——该分片不分片，该拆锁不拆锁 -
RLock()临界区过大，比如在锁内做 DB 查询或序列化，把并发优势全吃掉了 - 本可用
atomic.Int64或atomic.Value的场景，硬上了锁（如单个计数器、不可变配置快照）
比选锁更重要的，是命名清晰（如 cacheMu、statsMu）、保护范围精准、以及用 go tool trace 真实看锁竞争热点——凭感觉猜，十次九错。
