公平锁和非公平锁
一、如果一个锁是公平的，那么获取的顺序就应该符合请求的绝对顺序，即FIFO。
二、测试结果
非公平性锁可能使线程“饥饿”，为什么它又被设定成默认的实现呢？再次观察上表的结
果，如果把每次不同线程获取到锁定义为1次切换，公平性锁在测试中进行了10次切换，而非
公平性锁只有5次切换，这说明非公平性锁的开销更小。
三、，公平性锁保证了锁的获取按照FIFO原则，而代价是进行大量的线程切换。非公平性锁虽
然可能造成线程“饥饿”，但极少的线程切换，保证了其更大的吞吐量。
读写锁
一、之前提到锁（如Mutex和ReentrantLock）基本都是排他锁，这些锁在同一时刻只允许一个线
程进行访问，而读写锁在同一时刻可以允许多个读线程访问，但是在写线程访问时，所有的读
线程和其他写线程均被阻塞。读写锁维护了一对锁，一个读锁和一个写锁，通过分离读锁和写
锁，使得并发性相比一般的排他锁有了很大提升。
在没有读写锁支持的（Java 5之前）时候，如果需要完成上述工作就要使用Java的等待通知
机制，就是当写操作开始时，所有晚于写操作的读操作均会进入等待状态，只有写操作完成并
进行通知之后，所有等待的读操作才能继续执行（写操作之间依靠synchronized关键进行同
步），这样做的目的是使读操作能读取到正确的数据，不会出现脏读。改用读写锁实现上述功
能，只需要在读操作时获取读锁，写操作时获取写锁即可。当写锁被获取到时，后续（非当前写
操作线程）的读写操作都会被阻塞，写锁释放之后，所有操作继续执行，编程方式相对于使用
等待通知机制的实现方式而言，变得简单明了。
二、因为大多数场景读是多于写的。在读多于写
的情况下，读写锁能够提供比排它锁更好的并发性和吞吐量。Java并发包提供读写锁的实现是
ReentrantReadWriteLock，
特性：
三、读写锁接口