Go高并发环境中避免读写锁死锁的防范准则演练-Golang-PHP中文网

sync.rwmutex本身不触发deadlock panic，但不当使用会导致静默卡死：写锁需等所有读锁释放，读锁在写锁等待时被阻塞，goroutine持续合法等待而cpu归零。

go高并发环境中避免读写锁死锁的防范准则演练

Go 高并发中 sync.RWMutex 本身不会直接引发 fatal error: all goroutines are asleep - deadlock!，但不当使用极易造成静默卡死（CPU 归零、goroutine 持续阻塞），尤其在读写混合、锁升级或嵌套场景下。核心问题不是“锁坏了”，而是你误以为读锁可无限叠加、写锁可随意插入——实际它有明确的获取优先级和阻塞规则。

为什么 RWMutex 会卡住而不报 panic？

sync.RWMutex 的设计决定了：一旦有 goroutine 正在写（Lock()），所有后续的读（RLock()）和写都会阻塞；而一旦有任意 goroutine 持有读锁，任何写操作都会等待所有读锁释放。它不触发运行时死锁 panic，是因为仍有 goroutine 在“合法等待”——只是这个等待可能永远持续。

常见静默卡死现象：

多个 goroutine 持有 RLock()，其中一个尝试 Lock() 升级，结果等不到所有读锁释放
写操作被大量并发读压住，迟迟无法获得独占权，下游依赖写结果的逻辑全挂起
在 RLock() 持有期间调用另一个也需 RWMutex 的函数，且两处锁顺序不一致（AB-BA）

读锁不能升级为写锁，这是铁律

Go 的 sync.RWMutex 不支持“读锁 → 写锁”升级。试图在已持有 RLock() 的 goroutine 中调用 Lock()，会导致该 goroutine 永久阻塞（因为写锁必须等所有读锁释放，而它自己还占着一个）。

正确做法是：提前释放读锁，再申请写锁 —— 但这中间存在竞态窗口。所以更稳妥的是：

不要在读路径里临时决定要写；把“读-判-写”逻辑拆成两个明确阶段
若必须原子化，改用普通 sync.Mutex，或用 CAS + atomic 替代锁
极端场景下，用 sync.Once 或 sync.Map 规避锁升级需求

避免 RWMutex 与 Mutex 混用导致的 AB-BA 死锁

当代码同时使用 sync.RWMutex 和 sync.Mutex（或多个 RWMutex），且不同 goroutine 以不同顺序获取它们时，循环等待立刻成立。

使用Go语言搭建家庭相册系统-相关课件

下载

例如：

var rw sync.RWMutex
var mu sync.Mutex
<p>// goroutine A:
rw.RLock()
mu.Lock() // 等 mu</p><p>// goroutine B:
mu.Lock()
rw.Lock() // 等 rw（因 A 持有 RLock，写锁需等全部读锁释放）
</p>

这种组合比纯 Mutex 更隐蔽，因为 RLock() 看似“无害”。防范方式只有一条：