ReentrantReadWriteLock的一些问题

前面对ReentrantReadWriteLock源码进行了分析,可以发现，ReentrantReadWriteLock揽括了公平锁、非公平锁，读锁、写锁等并发场景下常见的实现。相对于ReentrantLock，有者本质的提升。
在ReentrantLock中，读锁和写锁都是同等地位的，读和写都是独占锁。那么在ReentrantLock中，获取锁的过程如下：

可以看到，每次只有一个线程能获取到锁。读、写没有本质的不同，这样会造成ReentrantLock的性能比较低。将所有的操作都串行化处理。
上图就是采用公平锁之后的状态。
如果用非公平的方式，在每个线程获取锁的过程中，一上来如果遇到锁释放，而其他线程还没有获得锁的情形，那么这种情况下新加入的线程就可以进行一次锁竞争，有可能会获得锁。从而避免后续的排队操作。这样相对于每个操作都排队的情况，可以提升吞吐量。
在读写锁的情况下，将读锁与写锁进行了分离，这也是与我们现实生活中对应，写锁改变数据，因此需要独占，是排他锁。而读锁不改变数据，因此多个读操作之间可以共享。这样读写锁的过程如下图：

我们可以看到，写与写之间的过程都是分开的，写操作获得锁需要等前面其他的锁释放。而读与读之间的操作都是可以共享的。因此这样就让读操作效率大大增加，从而提升了整个锁的性能。
同样，在非公平锁模式的情况下，会带来吞吐量的进一步增加。个人理解，所谓公平锁，就是排队，将所有对锁的操作都入队，然后按FIFO进行。如果是非公平锁，则会在排队之前尝试一次抢锁。这样就会打破原有的FIFO，但是能够增加吞吐量。

需要说明的是，公平锁能通过排队保证锁的FIFO，但是降低了性能。非公平锁，带来了性能的提升，但是FIFO的平衡一旦打破，就会导致部分锁的等待线程一直等待，在相对时间内无法获得锁，从而造成饥饿。
在非公平模式下，对于ReentrantReadWriteLock而言，写操作虽然具有优先级，但是还是会排队的。这样就可能造成在特殊情况下，读锁饥饿问题，如果读操作非常多，写操作比较少，这样就导致写操作的及时性会低于预期。
因此，这也是后续StampedLock被引入的原因。通过StampedLock能很好的解决锁饥饿问题。