LZ/01

ARTICLE / Go · RWMutex

Go sync.RWMutex 的死锁拓扑与写优先调度陷阱

Go 的 sync.RWMutex 不支持重入且采用写优先调度：持有读锁再请求写锁会自锁，嵌套读锁撞上并发写请求会形成跨协程循环等待。本文用两段可复现代码讲清死锁拓扑，并给出禁止嵌套加锁、极限收敛临界区两条工程防护规范。

发布
阅读
约 3 分钟
作者
Nicolas Leigh
READS0次阅读

在读多写少的并发场景中，sync.RWMutex 常被用于降低读操作的互斥开销。但与部分语言（如 Java 的 ReentrantReadWriteLock）不同，Go 标准库中的读写锁不支持重入，且在调度层面采用了偏向写者（Writer-preference）的设计。若对底层的状态机流转与排队机制缺乏认知，极易在代码中埋下隐蔽的死锁隐患。

1. 锁升级陷阱：不可重入导致的自锁

在缓存更新逻辑中，常见一种直觉式的“原地升级”写法：先加读锁检查，未命中则直接加写锁写入。

var rw sync.RWMutex
var data string

func UpdateData() {
    rw.RLock()
    if data == "" {
        // 严重缺陷：持有读锁的同时请求写锁
        rw.Lock()
        data = "new_value"
        rw.Unlock()
    }
    rw.RUnlock()
}
  • 底层机制：Go 的同步原语不记录持有者的 Goroutine ID。执行 Lock() 时，运行时仅评估当前活动的读锁持有数与写等待队列。此时因当前协程自身正持有读锁，读锁计数器未归零，Lock() 将被调用挂起（gopark），等待读锁释放。
  • 死锁闭环：执行流被挂起后，后续的 RUnlock() 永远无法被执行，造成当前协程自我死锁。
  • 规避原则：Go 不支持原子性的锁升级。必须显式执行 RUnlock() 释放读锁后，再重新竞争 Lock()；重新获取写锁后，还必须对业务条件进行二次检查（Double-check）。

2. 幽灵死锁：写优先机制引发的跨协程死锁

相比直观的锁升级，更难排查的是嵌套读锁结合写请求所引发的死锁。

为了防止并发读请求无限期延迟写操作（即写饥饿，Write Starvation），Go 的 sync.RWMutex 实现了一套写优先调度策略：当有 Goroutine 正在等待获取写锁时，后续新到达的 RLock() 请求会被强行拦截并挂起，直到该写锁获取并释放完毕。

这一机制在读锁嵌套调用的链路中会演变为确定性死锁：

var rw sync.RWMutex

func RecursiveRead() {
    rw.RLock()
    // 模拟耗时或深层链路调用
    time.Sleep(50 * time.Millisecond)
    // 嵌套调用内部方法
    InnerRead()
    rw.RUnlock()
}

func InnerRead() {
    rw.RLock() // 死锁触发点
    // ...
    rw.RUnlock()
}

func Write() {
    rw.Lock()
    // ...
    rw.Unlock()
}

该死锁的形成依赖以下时序：

Goroutine A (Reader)            Goroutine B (Writer)
│                               │
1. rw.RLock() (外层获取成功)    │
│                               │
│                               2. rw.Lock() (被 A 阻塞，标记 readerWait)
│                               │
3. rw.RLock() (内层)────────────┘
(被写优先机制拦截，挂起等待 B 完成)

死锁依赖链：

  1. Goroutine A（内层读） 在等待 Goroutine B（写） 释放；
  2. Goroutine B（写） 正在等待当前所有的读锁释放，即等待 Goroutine A（外层读） 退出；
  3. Goroutine A（外层读） 的解锁指令必须等待内层逻辑执行完毕才能到达。

三者形成循环等待。该缺陷在单协程测试或低并发测试中无法暴露，仅在生产环境高频读链路上穿插写操作时偶发出现，排查成本极高。

3. 工程防护规范

规范一：消除锁的上下文传递（禁止嵌套加锁）

避免在公共函数或调用栈深层方法中重复加锁。若内部函数需要访问受保护资源，应将锁的粒度收敛在顶层调用者，底层函数通过传参接收已解保护的数据：

// 推荐：底层函数要求调用方保证并发安全性，自身不维护锁
func innerReadUnsafe(data string) {
    // 纯逻辑处理
}

func Caller() {
    rw.RLock()
    val := sharedData
    rw.RUnlock()
    innerReadUnsafe(val)
}

规范二：极限收敛临界区

临界区内应仅包含对共享内存的读写或浅拷贝操作，严禁将 I/O、RPC 调用、序列化等非确定性耗时逻辑置于锁内：

// 错误模式：网络 I/O 阻塞临界区，放大写饥饿与死锁概率
func Bad() {
    rw.RLock()
    defer rw.RUnlock()
    cfg := config["key"]
    http.Post("...", cfg)
}

// 生产规范：仅保护内存操作，就地释放
func Good() {
    rw.RLock()
    cfg := config["key"]
    rw.RUnlock()
    http.Post("...", cfg)
}

sync.RWMutex 并非无代价的并发加速器。一旦引入读写锁，就必须严格遵守不可重入原则与临界区隔离规范；当调用链路复杂、读写时序难以在静态代码层面保证单向依赖时，应优先考虑通过数据复制、原子操作（atomic.Value）或 Channel 管道重构并发模型。