在《Go精妙的互斥锁设计》一文中，我们详细地讲解了互斥锁的实现原理。互斥锁为了避免竞争条件，它只允许一个线程进入代码临界区，而由于锁竞争的存在，程序的执行效率会被降低。同时我们知道，只有多线程在共享资源中有写操作，才会引发竞态问题，只要资源没有发生变化，多线程读取相同的资源就是安全的。因此，我们引申出更细粒度的锁：读写锁。
什么是读写锁
读写锁是一种多读单写锁，分读和写两种锁，多个线程可以同时加读锁，但是写锁和写锁、写锁与读锁之间是互斥的。
读写锁对临界区的处理如上图所示。其中，t1时刻，由于线程1已加写锁，线程2被互斥等待写锁的释放；t2时刻，线程2已加读锁，线程3可以对其继续加读锁并进入临界区；t3时刻，线程3加了读锁，线程4被互斥等待读锁的释放。
饥饿问题
根据读写锁的性质，读者应该能猜到读写锁适用于读写分明的场景。根据优先级，可以分为读优先锁和写优先锁。读优先锁能允许最大并发，但是写线程可能被饿死；同理，写优先锁是优先服务写线程，这样读线程就可能被饿死。
相对而言，写锁饥饿的问题更为突出。因为读锁是共享的，如果当前临界区已经加了读锁，后续的线程继续加读锁是没问题的，但是如果一直有读锁的线程加锁，那尝试加写锁的线程则会一直获取不到锁，这样加写锁的线程一直被阻塞，导致了写锁饥饿。
同时，由于多读锁共享，可能会有读者问：为什么不直接去掉读锁，在写操作线程进来时只加写锁就好了呢，这样岂不是很好实现了。道理很简单，如果当前临界区加了写锁，在写锁解开之前又有新的写操作线程进来，等到写锁释放，新的写操作线程又上了写锁。这种情况如果连续不断，那整个程序就只能执行写操作线程，读操作线程就活活被饿死了。
所以，为了避免饥饿问题，通用的做法是实现公平读写锁，它将请求锁的线程用队列进行排队，保证了先入先出（FIFO）的原则进行加锁，这样就能有效地避免线程饥饿问题。
那Go语言的读写锁，对于饥饿问题，它是如何处理的呢？
Go读写锁设计
sync.RWMutexwsync.MutexwriterSemreaderSemreaderCountreaderWaitsync.RWMutexRLock()RUnlock()Lock()Unlock()下面，我们来依次分析。
加读锁
if race.Enabled {}atomic.AddInt32LOCKrw.readerCountruntime_SemacquireMutexrw.readerCountrw.readerCount解读锁
rrrUnlockSlowr+1==0rwmutexMaxReaders = 1 << 30r+1 == -rwmutexMaxReadersrw.readerWaitruntime_Semrelease读者此时只看了加解读锁的代码，理解上会有困难，不要急，我们接着看加解写锁的逻辑。
加写锁
在加写锁时，首先会通过互斥锁加锁，这保证只会有一个写锁加锁成功。当互斥锁加锁成功之后，我们就能看到写操作是如何阻止读操作，读操作是如何感知到写操作的。
rw.readerCountrw.readerCountatomic.AddInt32readerCountreaderCount这里需要格外注意的是：互斥锁加锁成功并不意味着加写锁成功。我们需要知道读操作是如何阻止写操作，写操作是如何感知到读操作的。
r != 0atomic.AddInt32rw.readerCountrw.readerWaitruntime_SemacquireMutexrw.readerCountrw.readerWaitrw.readerWait解写锁
在解写锁时，将负值的rw.readerCount变更为正值，解除对读锁的互斥，并唤醒r个因为写锁而阻塞的读操作goroutine。最后，通过调用互斥锁的Unlock方法，解除对写锁的互斥。
到这里，我们可以图解一下Go是如何解决饥饿问题的。
rw.readerCountrw.readerCountrw.readerCountrw.readerCountrw.readerCount总结
读写锁基于互斥锁，提供了更细粒度的控制，它适用于读写分明的场景，准确而言是读操作远多于写操作的情况。在多读少写的场景中，使用读写锁替代互斥锁能有效地提高程序运行效率。
读读共享、读写互斥和写写互斥。在优先级方面，偏袒读锁或者写锁要分几种情况。
atomic.AddInt32因为读写锁是基于互斥锁之上的设计，不可避免地多做了一些工作。因此，并不是说使用读写锁的收益一定会比互斥锁高。在选择何种锁时，需要综合考量读写操作的比例，临界区代码的耗时。性能比对的内容本文就不再讨论，读者可自行测试。