go读写锁
互斥锁每次只让一 g通过，去读写数据。但是读数据操作，并发其实没有问题。所以诞生了 读写锁。
读协程可以并发，一起读。但是 写协程还是要走互斥锁，只能一个个通过。
先加了读锁
先加了读锁。那么写的协程，就需要去休眠队列中等待。一直到读锁都释放。
先加了写锁
这个时候，不管再来 写协程还是读协程，都去休眠队列等待。
小结：
没有加写锁时，多个协程都可以加读锁
加了写锁时，无法加读锁，读协程排队等待
加了读锁，写锁排队等待
定义
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 atomic.Int32 // number of pending readers
readerWait atomic.Int32 // number of departing readers
}
w：互斥锁作为写锁
writerSem：作为写协程队列
readerSem：作为读协程队列
readerCount： 正值：正在读的协程 负值：加了写锁
readerWait：写锁应该等待读协程个数
有三个sema队列了，w本身底层有一个，readerSem 和 writerSem。
运行逻辑
当锁是一个初始化的状态，来了一个写协程
`rwmutexMaxReaders` 是一个非常大的常量
把readerCount 改成了一个 很大的负数
加写锁，有读协程已经在读了
来了写锁后，把 readerCount 也减去了一个很大的数，但是 3还是能从这个值中体现。
但是，当再有 读的g过来时候，发现readerCount 为负数，就会去readSem中休眠。
代码实现
读锁
加锁
func (rw *RWMutex) RLock() {
// 将readerCount+1，发现还是负的，就去休眠，说明有写锁在等待
if rw.readerCount.Add(1) < 0 {
runtime_SemacquireRWMutexR(&rw.readerSem, false, 0)
}
// 如果不是负数，则加锁成功，去读数据
}
小结：
将给readerCount无脑加-
如果readerCount是正数，加锁成功
如果readerCount是负数，说明被加了写锁，陷入`readerSem`
解锁
func (rw *RWMutex) RUnlock() {
// 将 readerCount 减去1， 如果 r 小于0，说明有写协程 在等待
if r := rw.readerCount.Add(-1); r < 0 {
// Outlined slow-path to allow the fast-path to be inlined
rw.rUnlockSlow(r)
}
}
func (rw *RWMutex) rUnlockSlow(r int32) {
// readerWait 写锁应该等待读协程个数 减去1（自身） 之后，
//如果是 0，说明没有 读协程在读取数据了 ，就去 `runtime_Semrelease `唤醒换一个写协程
if rw.readerWait.Add(-1) == 0 {
// The last reader unblocks the writer.
runtime_Semrelease(&rw.writerSem, false, 1)
}
}
读锁在解锁时候，去判断了 readerCount 是否小于0 是否有写协程在等待；然后再释放写协程，又判断了 readerWait 是否等于0，因为大于0，说明还有读协程。
小结：
给readerCountit减1
如果readerCount是正数，解锁成功，没有写协程在排队
如果readerCount是负数，有写锁在排队
如果自己是readerWait的最后一个，唤醒写协程
问题： 但是读锁在加锁时候，并没有 给
readerWait加值，这里判断是否有效呢 ？
写锁
加锁
func (rw *RWMutex) Lock() {
rw.w.Lock() // 先去加互斥锁，加上了再执行下面的逻辑，加不上直接去 w的sema中休眠了
r := rw.readerCount.Add(-rwmutexMaxReaders) + rwmutexMaxReaders
// 判断 r是否为0, 等于0 则直接加锁成功了。
if r != 0 && rw.readerWait.Add(r) != 0 {
runtime_SemacquireRWMutex(&rw.writerSem, false, 0)
}
}
讲下这里不为0的情况，如果r不为0，比如r为2，则说明还有2个读协程在工作。
rw.readerWait.Add(r)这句代码，正好解释了上面的问题。这里给 readerWait 赋值了，所以读协程在解锁时候，判断这个值才有用。
如果不来写协程，那这个
readerWait没有意义，因为这是判断是否释放写协程的。
那有没有lock()被两个 写协程 先后连续执行，让 r 的值为一个很大的负数？
不会。因为要先去加 互斥锁。一个写协程加上后，其他的写协程只能去 sema中等待。上篇有讲过。 所以上面有一个举例的图其实是有问题的。
小结加写锁：
先加mutex写锁，若已经被加写锁会阻塞等待
将readerCount变为负值，阻塞读锁的获取
计算需要等待多少个读协程释放
如果需要等待读协程释放，陷入writerSem
解写锁
func (rw *RWMutex) Unlock() {
r := rw.readerCount.Add(rwmutexMaxReaders)
// 去释放读协程，没有去释放 `writerSem`里面的写协程，因为这里面根本不会有休眠的写协程
for i := 0; i < int(r); i++ {
runtime_Semrelease(&rw.readerSem, false, 0) // 释放读协程
}
rw.w.Unlock() // 解锁 互斥锁，让互斥锁的sema等待队列中的协程，重新去竞争锁
}
小结 解写锁 ：
将readercount变为正值，允许读锁的获取
释放在readerSem中等待的读协程 上面讲了，这个时候 writerSem 是空的
解锁mutex
适合场景
适合读多写少的场景，如果都是写的场景，其实和互斥锁一样。