所有已知实现类：

ReentrantReadWriteLock
```
public interface ReadWriteLock
```
ReadWriteLock维护一对关联的locks ，一个用于只读操作，另一个用于写入。只要没有写入器， read lock可以由多个读取器线程同时保持。 write lock是独家的。
所有ReadWriteLock实现必须保证writeLock操作的内存同步效果（如Lock接口中所指定）也相对于关联的readLock 。也就是说，成功获取读锁定的线程将看到在先前释放写锁定时所做的所有更新。

读写锁允许访问共享数据的并发性高于互斥锁允许的并发性。它利用了这样一个事实：虽然一次只有一个线程（一个编写器线程）可以修改共享数据，但在许多情况下，任何数量的线程都可以同时读取数据（因此读取器线程）。理论上，使用读写锁所允许的并发性的增加将导致相互使用互斥锁的性能提高。实际上，这种并发性的增加只能在多处理器上完全实现，并且只有在共享数据的访问模式合适时才能实现。

读写锁是否会提高使用互斥锁的性能取决于与被修改相比读取数据的频率，读写操作的持续时间以及数据的争用 - 是，将尝试同时读取或写入数据的线程数。例如，最初填充数据并且之后不经常修改但经常搜索的集合（例如某种目录）是使用读写锁的理想候选者。但是，如果更新变得频繁，那么数据的大部分时间都会被完全锁定，并且并发性几乎没有增加。此外，如果读取操作太短，则读写锁定实现的开销（其本质上比互斥锁定更复杂）可以支配执行成本，特别是因为许多读写锁定实现仍然通过序列化所有线程。小部分代码。最终，只有分析和测量才能确定使用读写锁是否适合您的应用。

尽管读写锁的基本操作是直截了当的，但实现必须做出许多策略决策，这可能会影响给定应用程序中读写锁的有效性。这些政策的例子包括：
- 在写入器释放写锁定时，当读取器和写入器都在等待时，确定是否授予读锁定或写锁定。作家偏好很常见，因为写作预计很短且不常见。读者偏好不太常见，因为如果读者频繁且长期按预期，它可能导致写入的长时间延迟。公平或“有序”实施也是可能的。
- 确定在读取器处于活动状态且写入器正在等待时请求读锁定的读取器是否被授予读锁定。读者的偏好可以无限期地延迟写入者，而对作者的偏好可以减少并发的可能性。
- 确定锁是否可重入：具有写锁的线程是否可以重新获取它？它可以在保持写锁定的同时获得读锁定吗？读锁本身是否可重入？
- 写锁是否可以降级为读锁而不允许介入的写入器？读锁可以升级到写锁，优先于其他等待的读者或编写者吗？
在评估给定实现对应用程序的适用性时，您应该考虑所有这些事情。
从以下版本开始：

1.5

另请参见：

ReentrantReadWriteLock ， Lock ， ReentrantLock

方法摘要

所有方法实例方法抽象方法
变量和类型	方法	描述
`Lock`	`readLock()`	返回用于读取的锁。
`Lock`	`writeLock()`	返回用于写入的锁。

- 方法详细信息
  - readLock
```
Lock readLock()
```
    返回用于读取的锁。
    
    结果
    
    用于阅读的锁
  - writeLock
```
Lock writeLock()
```
    返回用于写入的锁。
    
    结果
    
    用于写作的锁

Interface ReadWriteLock

方法摘要

方法详细信息

readLock

writeLock