Go RWMutex 源码分析：一个计数器，如何把“读多写少”做得又快又稳

前言

Go读写锁sync.RWMutex（对应源码src/sync/rwmutex.go）是标准库中设计精妙的同步工具，其核心语义清晰明确：支持任意多个读者同时持有读锁，或仅允许一个写者持有写锁；当有写者等待获取锁时，新的读者会被阻塞，以此避免写者出现饥饿问题。

先看结论：这把锁巧妙在哪里

RWMutex的设计精髓并非单纯支持读写分离，而是通过一个读者计数器 readerCount，同时承载两层核心信息：

当前持有读锁的活跃读者数量；
系统中是否已有写者发起加锁请求。

源码中定义常量rwmutexMaxReaders = 1 << 30作为"写者到来"的判定阈值：当写者申请写锁时，会将readerCount一次性减去该常量，使其变为负数；后续所有新的读锁申请（RLock）检测到readerCount为负数时，便会知晓有写者在等待，随即进入阻塞队列。这一设计极为精炼，实现了一个整数同时兼顾状态位和计数器的双重功能。

go 复制代码

// 源码中核心常量定义
const rwmutexMaxReaders = 1 << 30

结构体设计：字段精简，职责边界清晰

RWMutex的结构体仅包含五个核心字段：w Mutex、writerSem、readerSem、readerCount、readerWait，没有冗余的字段堆砌，而是将复杂的读写同步问题拆解为多个独立子问题，每个字段各司其职：

w：专门解决写者之间的互斥竞争，保证同一时间只有一个写者能发起加锁流程；
writerSem/readerSem：两个信号量分别负责写者等待读者 、读者等待写者的阻塞与唤醒；
readerCount：记录活跃读者总数，同时携带写者到来的状态信号；
readerWait：统计当前仍持有读锁、未退出的活跃读者数量。

这种设计遵循核心原则：互斥归互斥，排队归排队，状态归状态 。Mutex仅处理写者间的竞争，readerCount仅标识系统当前的锁状态，信号量仅负责阻塞与唤醒的调度，各组件职责边界干净，逻辑可推理性强。

go 复制代码

// RWMutex 结构体源码
type RWMutex struct {
    w           Mutex        // 写者间互斥锁
    writerSem   uint32       // 写者等待读者的信号量
    readerSem   uint32       // 读者等待写者的信号量
    readerCount int32        // 活跃读者计数器（含写者状态）
    readerWait  int32        // 等待退出的读者数量
}

`RLock`：读锁为什么能快

读锁RLock的高性能核心在于快路径极短 ，核心流程仅为原子操作+条件判断：对readerCount执行原子加1操作，若操作后结果仍为非负数，说明当前无写者等待，读者可直接进入临界区；仅当结果为负数时，读者才会在readerSem上阻塞睡眠。

在"读多写少"的典型场景中，读者几乎都走快路径，无需执行复杂的阻塞等待逻辑，这是读锁高性能的关键。

源码注释中明确指出，RLock不适合用于递归读锁 ：若有写者调用Lock申请写锁并进入阻塞后，新的读锁申请会被直接挡住，直到写者成功获取并释放写锁后才能继续，这一设计的核心目的是保障写者的锁获取权，避免写者饥饿。

go 复制代码

// RLock 读锁申请源码
func (rw *RWMutex) RLock() {
    // 原子加1，快路径核心操作
    if atomic.AddInt32(&rw.readerCount, 1) < 0 {
        // 若结果为负，说明有写者等待，阻塞读者
        runtime_SemacquireMutex(&rw.readerSem, false, 0)
    }
}

`Lock`：写锁为什么能"让新读者停下"

写锁Lock的核心能力是"阻断新读者，等待旧读者"，其执行流程极具代表性：

调用w.Lock()，解决多个写者之间的竞争，保证同一时间只有一个写者执行后续操作；
将readerCount减去rwmutexMaxReaders，让其变为负数，向所有后续读锁申请发出信号："写者已到，新读者请排队"；
若此时仍有活跃读者持有读锁，将活跃读者数量记录到readerWait，随后写者在writerSem上阻塞，直到最后一个读者释放读锁。

这一设计的精妙之处在于：写者不会强行抢占读者的锁资源，而是先关闭新读者的进入通道，再等待当前持有读锁的读者全部退出。

也正因如此，当某个goroutine调用Lock且锁正被读者持有时，后续的RLock都会被阻塞，直到写者完成加锁、执行业务并释放锁，这是一种写者优先的防饥饿设计策略。

go 复制代码

// Lock 写锁申请源码
func (rw *RWMutex) Lock() {
    // 1. 写者间互斥，保证唯一写者进入
    rw.w.Lock()
    // 2. 减去阈值，标记写者到来，阻断新读者
    r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders
    // 3. 若仍有活跃读者，记录数量并阻塞等待
    if r != 0 && rw.readerWait.Add(r) != 0 { // readerWait + 如果不为0就表示还是有写未释放
        runtime_SemacquireRWMutex(&rw.writerSem, false, 0)
    }
}

`RUnlock` 和 `Unlock`：唤醒顺序是稳定性的关键

读锁释放RUnlock和写锁释放Unlock的逻辑高度适配，且唤醒与状态恢复的顺序经过严格设计，是保证RWMutex稳定运行的核心：

RUnlock：读锁释放

逻辑精炼且区分普通场景与写者等待场景：

对readerCount执行原子减1操作；
若操作后结果仍为非负数，说明无写者等待，仅为普通读者退出，流程直接结束；
若操作后结果为负数，说明有写者在阻塞等待，进入慢路径rUnlockSlow，对readerWait执行减1操作；当readerWait减至0时，说明最后一个读者已退出，随即释放writerSem唤醒写者。

go 复制代码

// RUnlock 读锁释放源码
func (rw *RWMutex) RUnlock() {
    // 原子减1，判断是否有写者等待
    if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
        // 有写者等待，进入慢路径
        rw.rUnlockSlow(r)
    }
}

// rUnlockSlow 读锁释放慢路径（有写者等待时）
func (rw *RWMutex) rUnlockSlow(r int32) {
    // 读者等待数减1，判断是否为最后一个读者
    if atomic.AddInt32(&rw.readerWait, -1) == 0 { // 注：readerWait可能是负数，rw.readerWait.Add(r) 还没执行到，但是不影响逻辑，因为等于0是还是会唤醒writerSem
        // 最后一个读者退出，唤醒写者
        runtime_Semrelease(&rw.writerSem, false, 1)
    }
}

Unlock：写锁释放

流程与Lock完全逆向，严格遵循先恢复读者态，再批量唤醒读者，最后放开写者互斥的顺序：

将readerCount加回rwmutexMaxReaders，将系统从"写者占用态"恢复为正常的"可读态"；
根据实际数量释放readerSem，批量唤醒所有因写者等待而被阻塞的读者；
调用w.Unlock()，释放写者间的互斥锁，允许下一个写者参与锁竞争。

这一固定的执行顺序，从根本上避免了读写唤醒的逻辑混乱，是整个实现稳定性的关键。

go 复制代码

// Unlock 写锁释放源码
func (rw *RWMutex) Unlock() {
    // 1. 恢复readerCount，退出写者占用态
    r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
    // 2. 批量唤醒阻塞的读者（r为阻塞的读者数量）
    for i := 0; i < int(r); i++ {
        runtime_Semrelease(&rw.readerSem, false, 0)
    }
    // 3. 释放写者间互斥锁，允许下一个写者竞争
    rw.w.Unlock()
}

最值得学习的设计点

1. 用负数编码"写者已到"的状态

这是RWMutex最经典的设计技巧，让普通的计数器readerCount成为带状态意义的计数器：通过减去超大常量使其变负，用数值的符号直接标识系统状态------非负表示无写者，仅存在读者；负数表示有写者已发起申请。后续读锁仅需判断符号，即可快速决定执行路径，无需额外的标志位变量。

2. "门闩"与"人数统计"解耦

w Mutex作为写者间的"门闩"，仅负责写者的串行化，不直接干预读者的逻辑；readerWait仅作为"人数统计"工具，记录未退出的读者数量，不参与锁状态的判定。这种解耦设计让算法逻辑更清晰，也为TryLock、RLocker等附加功能的扩展提供了便利。

go 复制代码

// RLocker 返回读锁的Locker接口实现（解耦扩展示例）
func (rw *RWMutex) RLocker() Locker {
    return (*rlocker)(rw)
}

type rlocker RWMutex

func (r *rlocker) Lock()   { (*RWMutex)(r).RLock() }
func (r *rlocker) Unlock() { (*RWMutex)(r).RUnlock() }

3. 双信号量拆分唤醒方向

为读者和写者分别设计独立的信号量readerSem和writerSem，是极具工程价值的设计：

写者仅需在writerSem上等待最后一个读者的唤醒，无需关注读者的其他逻辑；
读者仅需在readerSem上等待写者的唤醒，逻辑单一；
读写的阻塞与唤醒逻辑完全分离，避免了"单个条件变量承载所有等待者，需额外判断唤醒对象"的复杂性。

4. 快路径内联，慢路径抽离

在RUnlock的实现中，将写者等待的慢逻辑抽离为独立的rUnlockSlow方法，核心目的是让普通场景的快路径更容易被编译器内联。这一思路是高频同步原语的性能设计准则：热路径尽量精简，冷路径单独抽离，也是Go标准库性能优化的典型风格。

5. 对`TryLock`/`TryRLock`保持克制

源码注释中明确表示，尽管TryLock（尝试加写锁）和TryRLock（尝试加读锁）的实现是正确的，但实际开发中合理的使用场景极少，且这类用法往往暗示着业务层的并发设计存在深层问题。

标准库并未将"尝试锁"包装为通用解决方案，而是提醒开发者避免将其作为常规设计，这一设计理念对并发编程实践具有重要的指导意义。

go 复制代码

// TryLock 尝试加写锁（源码示例，注释省略无关内容）
func (rw *RWMutex) TryLock() bool {
    if !rw.w.TryLock() {
			return false
    }
    if !rw.readerCount.CompareAndSwap(0, -rwmutexMaxReaders) {
			rw.w.Unlock()
			return false
    }
    return true
}

// TryRLock 尝试加读锁（源码示例，注释省略无关内容）
func (rw *RWMutex) TryRLock() bool {
    for {
        c := atomic.LoadInt32(&rw.readerCount)
        if c < 0 {
            return false
        }
        if atomic.CompareAndSwapInt32(&rw.readerCount, c, c+1) {
            return true
        }
    }
}

容易忽略的细节：非"线程所有权"模型

与Mutex一致，RWMutex的读锁和写锁均不与特定的goroutine绑定，即一个goroutine加锁后，可由另一个goroutine执行解锁操作。

这一设计对goroutine的并发编排极为友好，支持"一个协程负责获取资源加锁，另一个协程在合适时机释放资源解锁"的灵活使用模式，适配更多的业务并发场景。

这份源码教给我们的，不只是锁

将RWMutex作为并发设计的经典样本，其带给开发者的启发远不止锁的实现本身，更包含通用的并发设计思路：

状态编码极简化：避免将状态拆分为多个独立且难以一致维护的变量，一个带语义的复合变量（如带状态的计数器），往往比"计数器+标志位+排队数"的组合更高效、更稳定，也更易验证；
热路径极致精简：高频操作的快路径应尽可能缩短，仅保留核心的原子操作和简单判断，这是高性能同步原语的核心设计原则；
等待关系显式建模：并发中的"谁等谁"关系需显式设计，如用独立信号量承载读者等写者、写者等读者的逻辑，让整个同步协议的可推理性更强；
设计兼顾扩展性：组件职责的解耦与边界清晰，是保证同步原语可扩展的关键，让后续新增功能时无需大幅修改核心逻辑。

结语

sync.RWMutex的设计价值，不在于其实现了"并发读、独占写"的基础语义，而在于它将看似复杂的读写同步问题，通过极简的设计压缩为少量状态变量、两条唤醒通道和一条极短的读锁快路径。

它并非依靠复杂的逻辑实现功能，而是通过状态编码、职责拆分、唤醒分流、热路径极简四大设计技巧，将工程质量做到了极致。对于开发基础组件、并发框架、任务调度、缓存系统的开发者而言，这一实现是并发设计的经典范本，值得反复研读和借鉴。

源码路径：https://github.com/golang/go/blob/master/src/sync/rwmutex.go

我的小栈：https://itart.cn/blogs/2026/note/go-rwmutex-counter-for-fast-reads.html

Go RWMutex 源码分析：一个计数器，如何把“读多写少”做得又快又稳

前言

先看结论：这把锁巧妙在哪里

结构体设计：字段精简，职责边界清晰

RLock：读锁为什么能快

Lock：写锁为什么能"让新读者停下"

RUnlock 和 Unlock：唤醒顺序是稳定性的关键

RUnlock：读锁释放

Unlock：写锁释放

最值得学习的设计点

1. 用负数编码"写者已到"的状态

2. "门闩"与"人数统计"解耦

3. 双信号量拆分唤醒方向

4. 快路径内联，慢路径抽离

5. 对TryLock/TryRLock保持克制

容易忽略的细节：非"线程所有权"模型

这份源码教给我们的，不只是锁

结语

`RLock`：读锁为什么能快

`Lock`：写锁为什么能"让新读者停下"

`RUnlock` 和 `Unlock`：唤醒顺序是稳定性的关键

5. 对`TryLock`/`TryRLock`保持克制