java.util.concurrent.locks.ReadWriteLock 接口 源码

相关类图：

java.util.concurrent.locks.ReadWriteLock 源码： 

package java.util.concurrent.locks;

public interface ReadWriteLock {
    
    Lock readLock();

    Lock writeLock();
}

接口 ReadWriteLock

全部已知实现类：
    ReentrantReadWriteLock
 

    ReadWriteLock 维护了一对相关的锁，一个用于只读操做，另外一个用于写入操做。只要没有 writer，读取锁 能够由多个 reader 线程同时保持。写入锁 是独占的。成功获取读锁的线程会看到写入锁以前版本所作的全部更新。

 

    与互斥锁相比，读-写锁 容许对共享数据进行更高级别的并发访问。虽然一次只有一个线程（writer 线程）能够修改共享数据，但在许多状况下，任何数量的线程能够同时读取共享数据（reader 线程）。从理论上讲，与互斥锁相比，使用读-写锁所容许的并发性加强将带来更大的性能提升。

    与互斥锁相比，使用读-写锁可否提高性能则取决于读写操做期间读取数据相对于修改数据的频率，以及数据的争用——即在同一时间试图对该数据执行读取或写入操做的线程数。

    例如，某个最初用数据填充而且以后不常常对其进行修改的 collection，由于常常对其进行搜索（好比搜索某种目录），因此这样的 collection 是使用读-写锁的理想候选者。可是，若是数据更新变得频繁，数据在大部分时间都被写入锁 独占，这时，就算存在并发性加强，也是微不足道的。更进一步地说，若是读取操做所用时间过短，则读-写锁实现（它自己就比互斥锁复杂）的开销将成为主要的执行成本。最终，只有经过分析和测量，才能肯定应用程序是否适合使用读-写锁。

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

• 在 writer 释放写入锁时，reader 和 writer 都处于等待状态，在这时要肯定是授予读取锁仍是授予写入锁。Writer 优先比较广泛，由于预期写入所需的时间较短而且不那么频繁。Reader 优先不太广泛，由于若是 reader 正如预期的那样频繁和持久，那么它将致使对于写入操做来讲较长的时延。公平或者“按次序”实现也是有可能的。
• 在 reader 处于活动状态而 writer 处于等待状态时，肯定是否向请求读取锁的 reader 授予读取锁。Reader 优先会无限期地延迟 writer，而 writer 优先会减小可能的并发。
• 肯定是否从新进入锁：可使用带有写入锁的线程从新获取它吗？能够在保持写入锁的同时获取读取锁吗？能够从新进入写入锁自己吗？
• 能够将写入锁在不容许其余 writer 干涉的状况降低级为读取锁吗？能够优先于其余等待的 reader 或 writer 将读取锁升级为写入锁吗？

 

方法摘要

Lock	readLock()            返回用于读取操做的锁。
Lock	writeLock()            返回用于写入操做的锁。

 

readLock

Lock readLock()

返回：
用于读取操做的锁。
 

writeLock

 

Lock writeLock()

返回：
用于写入操做的锁。