当前位置：首页 > 文章列表 > Golang > Go问答 > Go RWMutex 读锁升级为写锁为什么会死锁

Go RWMutex 读锁升级为写锁为什么会死锁

来源：17golang原创 2026-09-12 15:57:33 0浏览收藏

遇到 Go 里的“读锁升级死锁”，先看调用顺序：如果同一个 goroutine 已经执行了 RLock()，又在没有执行 RUnlock() 的情况下调用 Lock()，它会一直等下去。原因不是写锁性能慢，而是 sync.RWMutex 没有把读锁原子升级为写锁的语义；写锁必须等所有读锁离开，当前 goroutine 却正占着其中一个读锁。

安全原则是：读阶段只观察并保存快照，先释放读锁；需要修改时再申请写锁，并在写锁内重新检查条件。若业务要求“检查和更新”不可被插入，就把这段状态放进单独的 Mutex 或专门的状态锁中。

要点速览

RLock 后直接 Lock 不是升级，而是互相等待。
释放读锁后重取写锁时，必须接受状态可能已经变化，并重新确认条件。
锁的复制、漏解锁和把外部调用放进临界区，都会把问题扩大。

为什么 RLock 后再 Lock 会卡住

下面的最小示例只用来说明等待关系，不需要在生产代码中保留。Lock 的调用点永远等不到返回，所以后面的 Unlock 也永远不会执行。

package main

import "sync"

func upgrade(mu *sync.RWMutex) {
	mu.RLock()
	defer mu.RUnlock() // 读阶段原本会在函数返回时释放读锁

	mu.Lock() // 错误：写锁等待所有读锁，包括当前持有的读锁
	defer mu.Unlock() // 只有 Lock 返回后才有机会登记写锁释放
}

把现象拆成两个条件就清楚了：RLock 允许多个读者同时进入；Lock 需要排除读者。当前 goroutine 不能“暂时保留读锁并把自己算作例外”，也不能靠再次调用 RLock 来完成升级。

调用状态	锁的实际要求	结果
已经持有 RLock	当前读者仍在锁内	可以继续读取，但不能升级
调用 Lock	等待全部读锁释放	当前 goroutine 被挂起
准备 RUnlock	需要先走过 Lock 返回点	形成自等待

Go sync.RWMutex 读锁升级写锁时当前 goroutine 与全部读锁释放条件形成等待关系的静态示意图 — 图1：读锁升级死锁的静态关系示意；当前 goroutine 必须释放 RLock 才能满足 Lock 的条件，但它又在等待 Lock 返回。

修复：释放读锁后重新获取写锁

最常见的改法是把读写阶段分开。读锁内只取出足够判断的快照，离开读锁后再申请写锁；由于等待期间别的 goroutine 可能已经完成更新，写锁内必须再次检查。

func (c *Cache) PutIfMissing(key, value string) bool {
	c.mu.RLock()
	_, exists := c.items[key] // 读锁只负责读取共享 map
	c.mu.RUnlock()
	if exists {
		return false
	}

	c.mu.Lock()
	defer c.mu.Unlock() // 写路径统一负责释放写锁
	if _, exists = c.items[key]; exists {
		return false // 重取写锁后复核，避免覆盖先到的结果
	}
	c.items[key] = value
	return true
}

这段写法解决的是死锁，不等于把整个“检查—写入”变成了无竞争事务。真正的原子性由写锁内的第二次检查保证。若检查需要调用数据库、网络或回调，不要把这些慢操作放进锁里；先取得结果，再用短临界区提交状态。

Go 缓存共享状态从读快照到 RUnlock 再到写锁条件复核的静态边界示意图 — 图2：安全更新方案的静态边界示意；读阶段只产生快照，写阶段重新确认条件后更新共享状态。

什么时候应该改用 Mutex 或单独状态锁

如果业务真正需要的是“判断状态并立刻更新”，读锁带来的并发读取收益可能不值得承担两阶段重检。此时用普通 sync.Mutex 把状态转换包起来，通常更容易证明正确。

func (c *Cache) PutIfMissing(key, value string) bool {
	c.mu.Lock()
	defer c.mu.Unlock() // 检查与写入共享同一把互斥锁
	if _, exists := c.items[key]; exists {
		return false
	}
	c.items[key] = value
	return true
}

还可以把“高频只读数据”和“需要原子变更的状态”拆开：前者由 RWMutex 保护，后者由独立 Mutex 保护。关键不是锁的名字，而是让一个不变量只由一条清晰的锁边界维护。