多线程（七）ReadWriteLock 和 ReentrantReadWriteLock

1、ReadWriteLock

ReadWriteLock 维护了一对相关的锁，一个用于读操作，另一个用于写操作。只要没有 writer线程，读锁可以由多个 reader 线程同时保持。但写锁是独占的。

//这是源码，最重要的是实现类
public interface ReadWriteLock {
    /**
     返回用于读取操作的锁。 
     */
    Lock readLock();

    /**
     返回用于写入操作的锁
     */
    Lock writeLock();
}

所有 ReadWriteLock 实现都必须保证 写锁操作的内存同步效果也要保持与相关读锁的联系。也就是说，成功获取读锁的线程会看到写锁之前版本所做的所有更新。

与互斥锁相比，读写锁允许对共享数据进行更高级别的并发访问。虽然一次只有一个线程（writer 线程）可以修改共享数据，但在许多情况下，任何数量的线程可以同时读取共享数据（reader 线程），读写锁利用了这一点。从理论上讲，与互斥锁相比，使用读写锁所允许的并发性增强将带来更大的性能提高。在实践中，只有在多处理器上并且只在访问模式适用于共享数据时，才能完全实现并发性增强。

与互斥锁相比，使用读写锁能否提升性能，则取决于读写操作期间读取数据相对于修改数据的频率，以及数据的争用——即在同一时间试图对该数据执行读取或写入操作的线程数。例如，某个最初用数据填充并且之后不经常对其进行修改的集合，因为经常对其进行搜索（比如搜索某种目录），所以这样的集合是使用读写锁的理想候选者。但是，如果数据更新变得频繁，数据在大部分时间都被写锁独占，这时，就算存在并发性增强，也是微不足道的。更进一步地说，如果读操作所用时间太短，则读写锁实现（它本身就比互斥锁复杂）的开销将成为主要的执行成本，在许多读写锁实现仍然通过一小段代码将所有线程序列化时更是如此。最终，只有通过分析和测量，才能确定应用程序是否适合使用读写锁。

尽管读写锁的基本操作是直截了当的，但实现仍然必须作出许多决策，这些决策可能会影响给定应用程序中读写锁的效果。这些策略的例子包括：

• 在 writer 线程释放写锁时，reader线程 和 writer 线程都处于等待状态，在这时要确定是授予读锁还是授予写锁。Writer 线程优先比较普遍，因为预期写入所需的时间较短并且不那么频繁。Reader 线程优先不太普遍，因为如果 reader 线程正如预期的那样频繁和持久，那么它将导致对于写操作来说较长的时延。公平或者“按次序”实现也是有可能的。
• 在 reader 线程处于活动状态而 writer线程 处于等待状态时，确定是否向请求读锁的 reader 线程授予读锁。Reader 线程优先会无限期地延迟 writer线程，而 writer 线程优先会减少可能的并发。
• 确定是否重新进入锁：可以使用带有写锁的线程重新获取它吗？可以在保持写锁的同时获取读锁吗？可以重新进入写锁本身吗？
• 可以将写锁在不允许其他 writer 线程干涉的情况下降级为读锁吗？可以优先于其他等待的 reader线程 或 writer线程 将读锁升级为写锁吗？

当评估给定实现是否适合您的应用程序时，应该考虑所有这些情况。

2、ReadWriteLock的实现类ReentrantReadWriteLock