RWMutex 写锁升级导致阻塞时的改造方案

如果一段代码已经拿到 sync.RWMutex 的读锁，随后又直接调用 Lock()，它可能一直卡在写锁申请处。原因不是调度器偶尔变慢，而是 Go 的 RWMutex 明确不支持把 RLock() 升级成 Lock()：写者要等已有读者全部释放，而当前 goroutine 又在等待自己释放读锁。

读锁升级为什么会卡住

RWMutex 允许多个读者同时进入，但同一时刻只能有一个写者。只要有 goroutine 调用 Lock()，新的 RLock() 就会等待写者完成，这样写者不会被不断到来的读请求饿死。

因此，下面这个想法并不成立：先用读锁判断对象不存在，再在同一个锁上切换为写锁创建对象。当前读锁必须先释放，写锁才有机会获得；但代码如果在释放前调用 Lock()，就形成了自我等待。

旧写法的问题在哪里

把“读取”和“必要时创建”塞进同一个读锁范围，是最容易触发这个问题的写法。关键错误在于 Lock() 执行时，RUnlock() 还没有发生。

package main

import "sync"

type Entry struct {
    Value string
}

type Store struct {
    mu   sync.RWMutex
    data map[string]*Entry
}

func (s *Store) GetOrCreateBad(key string) *Entry {
    s.mu.RLock()
    defer s.mu.RUnlock() // 读锁到函数返回前才释放
    if item, ok := s.data[key]; ok {
        return item
    }

    s.mu.Lock() // 错误：仍持有 RLock 时申请写锁，会等待自己释放读锁
    defer s.mu.Unlock()
    item := &Entry{Value: "new"} // 这里只是演示创建位置
    s.data[key] = item
    return item
}

把读后写拆成两段

最通用的改造是先在读锁内拿到足够的快照，然后立即释放读锁。接着申请写锁，并在真正写入前重新检查一次。重新检查不是多余步骤，因为释放读锁到重新获得写锁之间，其他 goroutine 可能已经完成了创建或修改。

func (s *Store) GetOrCreate(key string) *Entry {
    s.mu.RLock()
    item, ok := s.data[key]
    s.mu.RUnlock() // 先完整释放读锁，再考虑写入
    if ok {
        return item
    }

    s.mu.Lock()
    defer s.mu.Unlock() // 写入和重新检查处于同一个写临界区
    if item, ok = s.data[key]; ok {
        return item // 其他 goroutine 已创建，直接复用已有对象
    }
    item = &Entry{Value: "new"} // 只在确认仍不存在时创建
    s.data[key] = item
    return item
}

这段代码的核心不是“先读后写”四个字，而是写入前的二次判断。第一次读取用于降低已有数据的读竞争；第二次判断负责承接锁切换期间发生的并发变化。若创建动作本身很重，可以先在锁外准备不可变候选值，再在写锁内做最终校验和提交。

什么时候直接使用单写锁

如果读取、判断和修改本来就必须保持一个一致的临界区，拆分读写反而会增加重复检查和状态设计。此时直接使用 Lock() 更容易读懂，也不会产生升级问题。

func (s *Store) GetOrCreateWithWriteLock(key string) *Entry {
    s.mu.Lock()
    defer s.mu.Unlock() // 读取、判断、创建和写回一次完成
    if item, ok := s.data[key]; ok {
        return item
    }
    item := &Entry{Value: "new"} // 写锁保护 map 的首次写入
    s.data[key] = item
    return item
}

兼容边界与排查清单

• 不要复制已经使用过的 RWMutex，包含它的结构体也应通过指针传递；官方文档明确要求锁首次使用后不能复制。
• 每次 RLock 都要对应一次 RUnlock，每次 Lock 都要对应一次 Unlock，不要用跨层返回把释放责任藏起来。
• 返回内部可变对象时，锁释放后仍可能被其他 goroutine 修改；必要时返回值拷贝，或把对象生命周期纳入接口约束。
• 不要把 TryLock 当成升级替代品。它只能告诉你当前是否拿到写锁，不能自动完成读锁释放、条件重检和一致性设计。

排查阻塞时，先找同一把 RWMutex 的持有路径：确认当前 goroutine 是否仍有读锁，再看等待栈是否停在 Lock。如果存在读锁升级，优先改结构，不要只靠增加超时或重试掩盖锁关系。

常见问题

释放 RLock 后还需要重新判断吗？

需要。释放读锁期间状态可能已经改变，写锁拿到后必须重新读取共享状态，避免重复创建或覆盖其他 goroutine 的结果。

读锁升级能不能用两个 RWMutex 规避？

不建议把多把锁当成升级机制。它会引入新的锁顺序和一致性问题，除非能明确规定资源分区、获取顺序和回滚策略。

读操作很短，是否还要使用 RWMutex？

不一定。若读写临界区都很短，普通 Mutex 的规则更简单；只有读并发收益足以抵消重检和生命周期复杂度时，才值得保留 RWMutex。