compact1, compact2, compact3

java.util.concurrent.locks

Interface ReadWriteLock

所有已知实现类：

ReentrantReadWriteLock

public interface ReadWriteLock

A ReadWriteLock维护一对关联的locks ，一个用于只读操作，一个用于写入。 read lock可以由多个阅读器线程同时进行，只要没有作者。 write lock是独家的。

所有ReadWriteLock实现必须保证的存储器同步效应writeLock操作（如在指定Lock接口）也保持相对于所述相关联的readLock 。 也就是说，一个线程成功获取读锁定将会看到在之前发布的写锁定所做的所有更新。

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

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

虽然读写锁的基本操作是直接的，但是执行必须做出许多策略决策，这可能会影响给定应用程序中读写锁定的有效性。 这些政策的例子包括：

• 在写入器释放写入锁定时，确定在读取器和写入器都在等待时是否授予读取锁定或写入锁定。 作家偏好是常见的，因为写作预计会很短，很少见。 读者喜好不常见，因为如果读者经常和长期的预期，写作可能导致漫长的延迟。 公平的或“按顺序”的实现也是可能的。
• 确定在读卡器处于活动状态并且写入器正在等待时请求读取锁定的读取器是否被授予读取锁定。 读者的偏好可以无限期地拖延作者，而对作者的偏好可以减少并发的潜力。
• 确定锁是否可重入：一个具有写锁的线程是否可以重新获取？ 持有写锁可以获取读锁吗？ 读锁本身是否可重入？
• 写入锁可以降级到读锁，而不允许插入写者？ 读锁可以升级到写锁，优先于其他等待读者或作者吗？

在评估应用程序的给定实现的适用性时，应考虑所有这些问题。

从以下版本开始：

1.5

另请参见：

ReentrantReadWriteLock ， Lock ， ReentrantLock

方法摘要

Modifier and Type	Method and Description
Lock	readLock() 返回用于阅读的锁。
Lock	writeLock() 返回用于写入的锁。

方法详细信息

readLock

Lock readLock()

返回用于阅读的锁。

结果

用于阅读的锁

writeLock

Lock writeLock()

返回用于写入的锁。

结果

用于书写的锁