Go 并发RWMutex 读锁升级导致死锁怎么办

Go 并发代码里，如果一个 goroutine 已经拿到 sync.RWMutex 的读锁，又在同一条调用路径上直接申请写锁，最可靠的结论不是“锁竞争变慢”，而是：这条路径不能完成。因为写者出现等待后，新的读者会被挡住，而当前 goroutine 又必须先释放自己的读锁才能让写者继续；它却卡在了 Lock 上。

官方地址：https://pkg.go.dev/sync#RWMutex

Go 的 RWMutex 不提供读锁升级。把“读阶段判断”和“写阶段修改”拆成两个明确的锁区间，释放读锁后重新获取写锁，并在写锁内再次检查状态，才能避免把升级动作写成等待环。

• RLock 只能对应 RUnlock，不能直接变成 Lock。
• 写者一旦等待，新的 RLock 会被阻塞，递归读锁也可能因此卡住。
• 释放读锁再获取写锁后，原来的判断可能已经过期，必须重新检查。

为什么 RWMutex 不能把读锁升级成写锁

RWMutex 允许多个读者同时持有读锁，或者只允许一个写者持有写锁。官方文档明确说明，RLock 不能升级为 Lock，Lock 也不能降级为 RLock。

如果当前读者先调用 Lock，它会等所有读者退出；但它自己已经停在等待写锁的位置，没有机会执行后面的 RUnlock。因此，把读锁包在 defer 中，再在函数内部申请写锁，是典型的升级死锁。

func (s *Store) Ensure(key string) {
    s.mu.RLock()
    defer s.mu.RUnlock() // 这个释放动作要等函数返回才发生。
    if _, ok := s.items[key]; ok {
        return
    }
    s.mu.Lock() // 错误：仍持有 RLock 时申请写锁，不能完成升级。
    defer s.mu.Unlock() // 写锁拿不到时，这里的 defer 也不会执行。
    s.items[key] = loadValue(key)
}

排查重点是锁的责任和调用顺序，而不是先换一个锁类型。忘记 RUnlock、复制已经使用过的 RWMutex、多把锁获取顺序不一致，也会产生相似的卡住现象，但修复动作并不相同。

从调用现场识别升级死锁

如果同一调用栈已经经过 RLock，随后停在 RWMutex.Lock，而对应的 RUnlock 位于后续代码或函数退出处，就应优先怀疑读锁升级。还要记录谁在等待写锁、是否已有其他写者排队，以及解锁责任是否被辅助函数隐藏。

Go 的 RWMutex 在写者等待时会阻止新的读者进入，递归读锁不能假设总能成功。这个规则会让“再调用一个只读辅助函数”也变成阻塞点，所以应把读锁范围保持在短小、可见的代码区间。

把读阶段与写阶段拆开

常见修复是读锁只做快速判断，判断结束后立即释放；写锁负责最终修改，并在锁内重新确认状态。重新检查必不可少，因为两次加锁之间可能已经有另一个 goroutine 完成了写入。

type Store struct {
    mu    sync.RWMutex
    items map[string]string
}

func (s *Store) Ensure(key string) {
    s.mu.RLock()
    _, exists := s.items[key]
    s.mu.RUnlock() // 先结束读阶段，不能把读锁带进写阶段。
    if exists {
        return
    }

    s.mu.Lock()
    defer s.mu.Unlock() // 写阶段只在拿到写锁后建立成对释放。
    if _, exists := s.items[key]; exists {
        return // 其他 goroutine 可能已经先写入，必须以锁内状态为准。
    }
    s.items[key] = loadValue(key)
}

func loadValue(key string) string {
    // 示例只表达写入边界，真实代码可在锁外准备不会依赖共享状态的值。
    return "value:" + key
}

这个模式解决的是“检查后按需写入”的常见场景，并不自动让读阶段和写阶段构成不可分割的事务。真正要求检查与修改绝对连续时，应直接从一开始就使用写锁。

按一致性要求选择同步边界

如果锁内需要访问外部服务、等待 channel 或执行不可控回调，应把动作移到锁外，再用版本号、快照或重新检查保护共享状态。每个锁区间都应该有清晰的获取、使用和释放责任。

一张排障清单避免复发

• 每次 RLock 都有清晰的 RUnlock，错误返回路径也不能跳过释放。
• 搜索同一把锁上的 RLock 后是否出现 Lock，包括辅助函数间接调用。
• 确认 RWMutex 没有在首次使用后被复制。
• 需要原子检查与更新时，优先选择一个完整写锁区间，而不是模拟升级。
• 通过阻塞栈或阻塞剖析确认等待点，再对照锁的获取顺序和释放责任。

常见问题

先调用 RUnlock，再调用 Lock 就一定安全吗？

它能避免读锁升级死锁，但不保证此前的判断仍然成立。写锁内需要重新读取共享状态；如果检查和修改必须原子化，则应从开始就使用写锁。

能不能用 TryLock 代替升级？

TryLock 只能报告当前是否拿到写锁，不能把已经持有的读锁转换成写锁。它不是锁设计问题的通用补丁。

读锁递归也会造成类似问题吗？

会。写者等待时新的读锁可能被挡住，因此嵌套的 RLock 不能假设总能成功。