- 所有已知的实现类:
-
ReentrantReadWriteLock
public interface ReadWriteLock
一个
ReadWriteLock维护一对相关的锁，一个用于只读操作，另一个用于写入。读锁可以同时被多个读线程持有，只要没有写线程。写锁是独占的。
所有ReadWriteLock实现必须保证writeLock操作的内存同步效果（如Lock接口中指定的）也适用于相关的readLock。也就是说，成功获取读锁的线程将看到在上一个写锁释放时所做的所有更新。
读写锁允许更高级别的并发访问共享数据，这比互斥锁允许的要多。它利用了这样一个事实，即虽然一次只有一个线程（写线程）可以修改共享数据，但在许多情况下，任意数量的线程可以同时读取数据（因此是读线程）。理论上，使用读写锁可以增加并发性，从而提高性能，而不是使用互斥锁。实际上，只有在多处理器上，并且只有在共享数据的访问模式适当时，才能充分实现使用读写锁带来的增加的并发性。
读写锁是否能够提高性能，取决于数据被读取的频率与被修改的频率、读取和写入操作的持续时间以及数据的争用情况 - 即同时尝试读取或写入数据的线程数。例如，一个最初填充了数据并且之后很少修改，但频繁搜索（例如某种目录）的集合是使用读写锁的理想候选对象。然而，如果更新变得频繁，那么数据大部分时间都会被独占锁定，并且并发性几乎没有增加。此外，如果读操作太短，则读写锁实现的开销（本质上比互斥锁更复杂）可能会主导执行成本，特别是因为许多读写锁实现仍然通过一小部分代码串行化所有线程。最终，只有通过分析和测量才能确定使用读写锁是否适合您的应用程序。
虽然读写锁的基本操作很简单，但实现必须做出许多策略决策，这可能会影响读写锁在给定应用程序中的有效性。这些策略的示例包括:
- 确定在读者和写者都在等待时，在写者释放写锁时是否授予读锁或写锁。通常偏向于写者，因为写入预计是短暂且不频繁的。偏向于读者较少见，因为如果读者频繁且寿命长，则可能导致写入的长时间延迟。还可以实现公平或“按顺序”。
- 确定在一个读者活动且一个写者在等待时请求读锁的读者是否被授予读锁。对读者的偏好可能会无限期地延迟写者，而对写者的偏好可能会减少并发的潜力。
- 确定锁是否可重入: 拥有写锁的线程能否重新获取它? 在持有写锁的同时能否获取读锁? 读锁本身是否可重入?
- 写锁是否可以降级为读锁而不允许介入的写者? 读锁是否可以升级为写锁，而不允许其他等待的读者或写者?
- 自从:
- 1.5
- 参见:
-
Method Summary