Golang-RWMutex读写锁源码分析
本文已参与「新人创作礼」活动，一起开启掘金创作之路。
前言
在上文中我们理解了Golang中互斥锁Mutex的实现，还不知道的可以去看一下原文地址：http://124.223.167.77/archives/golmutex
但是即使中内部算法优化了效率之后，真的每次请求或者访问都需要加锁吗？有接触更多锁知识的小伙伴，应该知道还有一种锁叫读写锁，好了话不多说，开始表演吧！
什么是读写锁？
读写锁是一种多读单写锁，分读和写两种锁，多个线程可以同时加读锁，但是写锁和写锁、写锁与读锁之间是互斥的。
饥饿问题
根据读写锁的性质，明显是使用读大于写的场景，那么读的请求可以达到最高请求数量，但是那时候任意一个写请求会被互斥，那么写请求就很难才拿到锁。反之，如果是写锁先拿到锁，这时候读的请求有很多，而这个写请求比较慢一点，就会导致大量用户读取不到数据！所以无论是读锁还是写锁都有可能发生饥饿的问题！
为什么不直接去掉读锁?
如果当前临界区加了写锁，在写锁解开之前又有新的写操作线程进来，等到写锁释放，新的写操作线程又上了写锁,这种情况如果连续不断，那整个程序就只能执行写操作线程，读操作线程就活活被饿死了
如何避免饥饿？
所以，为了避免饥饿问题，通用的做法是实现公平读写锁，它将请求锁的线程用队列进行排队，保证了先入先出（FIFO）的原则进行加锁，这样就能有效地避免线程饥饿问题。
Go中的读写锁源码分析
// RWMutex是读写互斥锁。
// RWMutex不能在第一次使用后被复制。
// 禁止递归，直到第一个读锁被释放
type RWMutex struct {
w Mutex // 互斥操作
writerSem uint32
readerSem uint32
readerCount int32
readerWait int32
}
writerSem写操作goroutine阻塞等待信号量。最后一个阻塞写操作的读操作goroutine释放读锁时，会通知阻塞的写锁goroutine。readerSem读操作goroutine阻塞等待信号量。写锁goroutine释放写锁后，会通知阻塞的读锁goroutine。readerCount读操作goroutine数量。readerWait阻塞写操作goroutine的读操作goroutine数量。
下面我们从加锁和解锁的方法去解读整个读写锁！
RLock读锁方法
func (rw *RWMutex) RLock() {
if race.Enabled {
_ = rw.w.state
race.Disable()
}
if atomic.AddInt32(&rw.readerCount, 1) < 0 {
// A writer is pending, wait for it.
runtime_SemacquireMutex(&rw.readerSem, false, 0)
}
if race.Enabled {
race.Enable()
race.Acquire(unsafe.Pointer(&rw.readerSem))
}
}
如果此时没有写锁，则仅仅将rw.readerCount数目加1，然后直接退出，代表加读锁成功。
加读锁这个方法，其实就是用原子类atomic将readerCount读操作的协程数量加一，然后如果加完之后结果为负值则代表可以加读锁，
为什么加完后会有小于0的情况？
因为在写操作加锁时，会将所有读操作协程数量变为负值，通知读协程说我现在要写，你要等等，所以读锁这边判断为负值之后就利用同步库的sleep原语runtime_SemacquireMutex阻塞等待这些读操作结束，
当写锁解锁后，会将readerCount变为正值，此时如果读请求还要加锁，就不会小于0了，那么就直接加readerCount+1就好了，就没有阻塞了！
RUnlock解锁方法
func (rw *RWMutex) RUnlock() {
if race.Enabled {
_ = rw.w.state
race.ReleaseMerge(unsafe.Pointer(&rw.writerSem))
race.Disable()
}
if r := atomic.AddInt32(&rw.readerCount, -1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
if race.Enabled {
race.Enable()
}
}
将读操作goroutine数目-1，如果其数目r大于等于0，则直接退出，代表解读锁成功。否则，带着当前处于负值的数目r进入以下rUnlockSlow逻辑
为什么r>=0可以直接退出
因为如果readerCount大于等于0代表此时没有写锁正在进行，直接退出就可以了，如果是负值所以还需要进一步判断因为此时可能写锁并发的时候刚加上所以readerCount变负值了
func (rw *RWMutex) rUnlockSlow(r int32) {
// 未正确加上读锁，应抛错
if r+1 == 0 || r+1 == -rwmutexMaxReaders {
race.Enable()
throw("sync: RUnlock of unlocked RWMutex")
}
// 如果刚好加完等于0，说明阻塞的读协程数量为1，直接释放即可
if atomic.AddInt32(&rw.readerWait, -1) == 0 {
// 影响写协程阻塞的信号量-1
runtime_Semrelease(&rw.writerSem, false, 1)
}
}
如果r+1==0，则证明在解读锁时，其实并没有读goroutine加读锁；
rwmutexMaxReaders = 1 << 30，这代表读写锁所能接收的最大读操作goroutine数量。至于这里为什么r+1 == -rwmutexMaxReaders也代表并没有goroutine加读锁，同样留在下文解答。在没有加读锁的锁上解读锁，会抛出异常并panic。
rw.readerWait代表写操作被阻塞时，读操作goroutine数量。如果该值为1，代表当前是最后一个阻塞写操作的goroutine，则通过用于同步库的wakeup原语runtime_Semrelease唤醒阻塞的写操作goroutine。
因为就最后一个读协程了，没有什么锁不锁了直接解开谁也不影响谁😂！
Lock方法
func (rw *RWMutex) Lock() {
if race.Enabled {
_ = rw.w.state
race.Disable()
}
// 首先会通过互斥锁加锁，这保证只会有一个写锁加锁成功。
rw.w.Lock()
// Announce to readers there is a pending writer.
r := atomic.AddInt32(&rw.readerCount, -rwmutexMaxReaders) + rwmutexMaxReaders
// `r != 0` 即代表当前读操作goroutine不为0，这意味着写操作要等待排在前面的读操作结束后才算是加上写锁。写操作获得互斥锁后，通过`atomic.AddInt32`把`rw.readerCount`值拷贝到`rw.readerWait`中，用于标记排在写操作goroutine前面的读操作goroutine个数
if r != 0 && atomic.AddInt32(&rw.readerWait, r) != 0 {
runtime_SemacquireMutex(&rw.writerSem, false, 0)
}
if race.Enabled {
race.Enable()
race.Acquire(unsafe.Pointer(&rw.readerSem))
race.Acquire(unsafe.Pointer(&rw.writerSem))
}
}
在加写锁时，首先会通过互斥锁加锁，这保证只会有一个写锁加锁成功。当互斥锁加锁成功之后，我们就能看到写操作是如何阻止读操作，读操作是如何感知到写操作的。
我们已经知道rw.readerCount是代表读操作goroutine数量，如果在不存在写操作的情况下，每次加读锁，该值就会+1，每次解读锁该值就会-1，那么我们可以合理地认为rw.readerCount的取值范围是[0,rwmutexMaxReaders],即最大支持2^30个并发读，最小是0个。
然而，在当前写操作goroutine加互斥锁成功后，会通过原子操作atomic.AddInt32将readerCount减去2^30，此时readerCount会变成负值，那么如果之后再有读操作goroutine加读锁时，能通过该负值知道当前已经有写锁了，从而阻塞等待。这里也解释了加读锁和解读锁两小节中留下的问题。最后，为了持有真实的读操作goroutine数目，再加回2^30即可。
这里需要格外注意的是：互斥锁加锁成功并不意味着加写锁成功。我们需要知道读操作是如何阻止写操作，写操作是如何感知到读操作的。
r != 0 即代表当前读操作goroutine不为0，这意味着写操作要等待排在前面的读操作结束后才算是加上写锁。写操作获得互斥锁后，通过atomic.AddInt32把rw.readerCount值拷贝到rw.readerWait中，用于标记排在写操作goroutine前面的读操作goroutine个数。通过用于同步库的sleep原语runtime_SemacquireMutex阻塞等待这些读操作结束。在解读锁小结中我们知道，读操作结束时，除了会递减rw.readerCount，同时需要递减rw.readerWait值，当rw.readerWait值变为0时就会唤醒阻塞的写操作goroutine。
读操作如何影响到写操作
读操作结束时，除了会递减rw.readerCount，同时需要递减rw.readerWait值，当rw.readerWait值变为0时就会唤醒阻塞的写操作goroutine。
写操作如何影响到读操作
在当前写操作goroutine加互斥锁成功后，会通过原子操作atomic.AddInt32将readerCount减去2^30，此时readerCount会变成负值，那么如果之后再有读操作goroutine加读锁时，能通过该负值知道当前已经有写锁了，从而阻塞等待。
UnLock方法
func (rw *RWMutex) Unlock() {
if race.Enabled {
_ = rw.w.state
race.Release(unsafe.Pointer(&rw.readerSem))
race.Disable()
}
// Announce to readers there is no active writer.
r := atomic.AddInt32(&rw.readerCount, rwmutexMaxReaders)
if r >= rwmutexMaxReaders {
race.Enable()
throw("sync: Unlock of unlocked RWMutex")
}
// Unblock blocked readers, if any.
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0)
}
// Allow other writers to proceed.
rw.w.Unlock()
if race.Enabled {
race.Enable()
}
}
在解写锁时，将负值的rw.readerCount变更为正值，解除对读锁的互斥，并唤醒r个因为写锁而阻塞的读操作goroutine。最后，通过调用互斥锁的Unlock方法，解除对写锁的互斥。
Go如何解决饥饿问题
假设G1、G2、G3是正在共享读的goroutine，rw.readerCount值为3。此时写操作G4进来，把rw.readerCount值变为了负值，同时它发现rw.readerCount不为0，因此阻塞等待。但是在G4的等待期间又有新的读操作G5、G6和写操作G7进来。由于此时的rw.readerCount值为负，所以G5和G6是不能加读锁成功的，会陷入阻塞等待。G7由于G4加了互斥锁也会陷入等待。当排在写操作G4前面的最后一个读操作G3结束，G3会唤醒G4。当G4结束时，它将G5、G6和G7均唤醒。但是G7需要等待G5和G6退出（因为它在试图加写锁时，会发现rw.readerCount不为0，会再次陷入阻塞等待）才能加写锁成功。以此反复，保证了读写锁的相对公平，避免一方挨饿。
最后总结
读写锁基于互斥锁，提供了更细粒度的控制，它适用于读写分明的场景，准确而言是读操作远多于写操作的情况。在多读少写的场景中，使用读写锁替代互斥锁能有效地提高程序运行效率。
读读共享、读写互斥和写写互斥。在优先级方面，偏袒读锁或者写锁要分几种情况。
- 锁空闲，此时是完全公平的，谁先进来谁就可以上锁。
- 如果没有读操作，均是写操作，读写锁会退化成互斥锁，只有在互斥锁处于饥饿模式下才会公平。
- 如果没有写操作，均是读操作，读操作均可以进来，读写锁退化成无锁设计（也并不是真正的无锁，因为加解锁均有原子操作
atomic.AddInt32对读操作goroutine的统计）。 - 被加读锁时，写操作进来会被阻塞。在写操作阻塞期间，如果有读操作试图进来，它们也会被阻塞。当阻塞写操作的最后一个读操作解读锁时，它只会唤醒被阻塞的写操作，之后进来的读操作需要该写操作完成之后被唤醒。这些被唤醒的读操作会比新的写操作（可以是新来的，也可以是因互斥锁而被阻塞的）先拿到锁，等待这些读操作完成，新的写操作才能拿到写锁。
