Go语言互斥锁Mutex与读写锁RWMutex竞争模型分析-Golang-PHP中文网

读占比≥90%时rwmutex吞吐可达mutex的2–5倍，70%–85%仍有优势但要求临界区极轻，≤60%性能持平而死锁风险陡增，≤40%时mutex耗时低20%～35%且延迟更稳。

go语言互斥锁mutex与读写锁rwmutex竞争模型分析

别盲目换 sync.RWMutex，读写比低于 70% 时它大概率拖慢程序、卡死写 goroutine，不是“更细粒度就更好”，而是“读够多、写够轻、临界区够短”才值得用。

sync.RWMutex 写锁卡死的三个真实原因

它卡住不是因为“没人释放读锁”，而是因为写锁必须等所有已持有的读锁全部释放完——而这些读锁可能正卡在耗时操作里。

RLock() 后做了 HTTP 请求、DB 查询或 json.Marshal()，导致该读 goroutine 长时间不调 RUnlock()，所有写请求全堵在 runtime.gopark
写请求排队期间，新来的读请求仍能抢到 readerSem，形成“读等写、写等读”的隐性循环，pprof/goroutine 里只看到一堆 sync.runtime_SemacquireMutex
大量短生命周期读 goroutine 持续抢占 readerSem，写 goroutine 长期得不到唤醒（这不是典型写饥饿，而是读侧资源争抢反向压制）

读写比多少才该切 RWMutex？看实测，不看理论

性能拐点非常陡峭，不是线性过渡：

读 ≥ 90%：吞吐可达 sync.Mutex 的 2–5 倍，适合配置拉取、监控指标批量 Load()
读 70%–85%：仍有优势，但要求读临界区极轻——只做 map[key] 查找，不能含任何 IO 或序列化
读 ≤ 60%：性能基本持平，但死锁风险陡增；≤ 40% 时 sync.Mutex 耗时低 20%～35%，延迟更稳

RLock() 里调 Lock() 必死锁，且 defer 救不了

Go 的 sync.RWMutex 不支持读锁升级。下面这段代码会永远卡住：

Go语言（Golang）1.26.0

Go语言（Golang）1.26.0版本官方下载，版本号 1.26.0，适合旧项目维护、兼容性测试和指定版本开发环境搭建。

下载

func (c *Counter) IncrementIfZero() {
    c.mu.RLock()
    defer c.mu.RUnlock() // ❌ defer 在函数返回才执行，但下一行已死锁
    if c.value == 0 {
        c.mu.Lock() // ⚠️ 等待自己释放 RLock
        c.value++
        c.mu.Unlock()
    }
}

正确做法是显式 c.mu.RUnlock() 后再 c.mu.Lock()，或者改用 double-check + 独立临界区。注意：defer 无法挽救这种结构。