数据结构

源码包 src/sync/rwmutex.go 中定义了读写锁数据结构：

type RWMutex struct {  w           Mutex  // held if there are pending writers  writerSem   uint32 // semaphore for writers to wait for completing readers  readerSem   uint32 // semaphore for readers to wait for completing writers  readerCount int32  // number of pending readers  readerWait  int32  // number of departing readers}

• w：用于控制多个写锁，获得写锁首先要获取该锁，如果有一个写锁在进行，那么再到来的写锁将会阻塞于此

• writerSem： 写阻塞等待的信号量，最后一个读者释放锁时会释放信号量

• readerSem：读阻塞的协程等待的信号量，持有写锁的协程释放锁后会释放信号量

• readerCount：记录读者的个数

• readerWait：记录写阻塞时读者的个数

由此可见，读写锁内部还有一个互斥锁，用来将两个写操作隔离开，其他的几个用于隔离读操作和写操作。

接口定义

RWMutex 提供了 4 个接口来：

• Rlock() : 读锁定

• RUnlock() : 解除读锁定

• Lock() : 写锁定，与 Mutex 一致

• Unlock() : 解除写锁定，与 Mutex 一致

Lock()实现逻辑

写操作所做的两件事：

1. 获取互斥锁

2. 阻塞等待所有读操作结束（如果有）

func (rw *RWMutex) Lock() 接口实现流程：

Unlock()实现逻辑

解除写操作所做的两件事：

1. 唤醒因读锁定而被阻塞的协程（如果有）

2. 解除互斥锁

func (rw *RWMutex) Unlock() 接口实现流程:

RLock()实现逻辑

读锁定所做的两件事：

1. 增加读操作计数，即 readerCount++

2. 阻塞等待写操作结束(如果有)

func (rw *RWMutex) RLock() 接口实现流程

RUnlock()实现逻辑

解除读锁定所做的两件事：

1. 减少读操作计数，即 readerCount—

2. 唤醒等待写操作的协程（如果有）

func (rw *RWMutex) RUnlock() 接口实现流程：

注意：只有最后一个解除读锁定的协程才会释放信号量，将协程阻塞等待写操作的协程唤醒。

使用场景

写操作阻止写操作

读写锁中包含一个互斥锁 Mutex，写操作必须先获取到此互斥锁，若此互斥锁已被其他协程获取，当前协程会阻塞等待该互斥锁。

写操作阻止读操作

RWMutex.readerCount 是个整型值，表示读者数量，不考虑写操作的情况下，每次读锁定会将该值+1，每次解除读锁定会将该值-1，所以 readerCount 的取值为[0, N]，N 为读者个数，实际上最大可支持 2^30 个并发读者。

当写锁定进行时，会先将 readerCount 减去 2^30，readerCount 就变成了负值，此时再有读锁定到来时检测到 readerCount 为负值，便知道有写操作在进行，只好阻塞等待。而真实的读操作个数并不会丢失，只需要将 readerCount 加上 2^30 即可获得。

所以，写操作将 readerCount 变成负值来阻止读操作的。

读操作阻止写操作

读锁定会先将 RWMutext.readerCount 加 1，此时写操作到来时发现读者数量不为 0，会阻塞等待所有读操作结束。

所以，读操作通过 readerCount 来将来阻止写操作的。

写锁定为什么不会被饿死

写操作要等待读操作结束后才可以获得锁，写操作等待期间可能还有新的读操作持续到来，如果写操作等待所有读操作结束，很可能被饿死。

然而，通过 RWMutex.readerWait 可完美解决这个问题。写操作到来时，会把 RWMutex.readerCount 值拷贝到 RWMutex.readerWait 中，用于标记排在写操作前面的读者个数。前面的读操作结束后，除了会递减 RWMutex.readerCount，还会递减 RWMutex.readerWait 值，当 RWMutex.readerWait 值变为 0 时唤醒写操作。

所以，如上图，前面的读操作结束后会唤醒写操作，写操作结束后会唤醒后面的读操作。