Interface - java.util.concurrent.locks.ReadWriteLock
Created by : Mr Dk.
2020 / 01 / 03 21:55
Nanjing, Jiangsu, China
Definition
public interface ReadWriteLock {
}
维护一对互相关联的锁
一个用于只读操作，一个用于只写操作
读锁可以被同时被多个读线程持有，只要没有写者
而写锁是互斥的
读写锁需要保证内存同步
- 即，一个成功获取读锁的线程将可以看到写锁释放之后的所有更新
读写锁对于共享数据比互斥锁允许更大程度的并发
- 同时只能有一个线程修改共享数据
- 而任意数量的线程可以同时读数据
读写锁能否在性能上超过互斥锁取决于:
- 数据被读或写的频率
- 对数据的碰撞
一些实现上需要注意的点
- 当读写线程都在等待时，分发读锁还是写锁
- 一般来说分配写锁，因为写操作不频繁，读操作将会导致写操作的饥饿
- 当存在一个活跃的读者和一个等待的写者时，分配读锁还是写锁
- 分配读锁会无限延迟写锁
- 分配写锁会降低并发性
- 锁是否可重入
- 锁的升级与降级
/**
* A {@code ReadWriteLock} maintains a pair of associated {@link
* Lock locks}, one for read-only operations and one for writing.
* The {@link #readLock read lock} may be held simultaneously by
* multiple reader threads, so long as there are no writers. The
* {@link #writeLock write lock} is exclusive.
*
* <p>All {@code ReadWriteLock} implementations must guarantee that
* the memory synchronization effects of {@code writeLock} operations
* (as specified in the {@link Lock} interface) also hold with respect
* to the associated {@code readLock}. That is, a thread successfully
* acquiring the read lock will see all updates made upon previous
* release of the write lock.
*
* <p>A read-write lock allows for a greater level of concurrency in
* accessing shared data than that permitted by a mutual exclusion lock.
* It exploits the fact that while only a single thread at a time (a
* <em>writer</em> thread) can modify the shared data, in many cases any
* number of threads can concurrently read the data (hence <em>reader</em>
* threads).
* In theory, the increase in concurrency permitted by the use of a read-write
* lock will lead to performance improvements over the use of a mutual
* exclusion lock. In practice this increase in concurrency will only be fully
* realized on a multi-processor, and then only if the access patterns for
* the shared data are suitable.
*
* <p>Whether or not a read-write lock will improve performance over the use
* of a mutual exclusion lock depends on the frequency that the data is
* read compared to being modified, the duration of the read and write
* operations, and the contention for the data - that is, the number of
* threads that will try to read or write the data at the same time.
* For example, a collection that is initially populated with data and
* thereafter infrequently modified, while being frequently searched
* (such as a directory of some kind) is an ideal candidate for the use of
* a read-write lock. However, if updates become frequent then the data
* spends most of its time being exclusively locked and there is little, if any
* increase in concurrency. Further, if the read operations are too short
* the overhead of the read-write lock implementation (which is inherently
* more complex than a mutual exclusion lock) can dominate the execution
* cost, particularly as many read-write lock implementations still serialize
* all threads through a small section of code. Ultimately, only profiling
* and measurement will establish whether the use of a read-write lock is
* suitable for your application.
*
*
* <p>Although the basic operation of a read-write lock is straight-forward,
* there are many policy decisions that an implementation must make, which
* may affect the effectiveness of the read-write lock in a given application.
* Examples of these policies include:
* <ul>
* <li>Determining whether to grant the read lock or the write lock, when
* both readers and writers are waiting, at the time that a writer releases
* the write lock. Writer preference is common, as writes are expected to be
* short and infrequent. Reader preference is less common as it can lead to
* lengthy delays for a write if the readers are frequent and long-lived as
* expected. Fair, or "in-order" implementations are also possible.
*
* <li>Determining whether readers that request the read lock while a
* reader is active and a writer is waiting, are granted the read lock.
* Preference to the reader can delay the writer indefinitely, while
* preference to the writer can reduce the potential for concurrency.
*
* <li>Determining whether the locks are reentrant: can a thread with the
* write lock reacquire it? Can it acquire a read lock while holding the
* write lock? Is the read lock itself reentrant?
*
* <li>Can the write lock be downgraded to a read lock without allowing
* an intervening writer? Can a read lock be upgraded to a write lock,
* in preference to other waiting readers or writers?
*
* </ul>
* You should consider all of these things when evaluating the suitability
* of a given implementation for your application.
*
* @see ReentrantReadWriteLock
* @see Lock
* @see ReentrantLock
*
* @since 1.5
* @author Doug Lea
*/
该接口只定义了两个函数
分别返回读锁和写锁
/**
* Returns the lock used for reading.
*
* @return the lock used for reading
*/
Lock readLock();
/**
* Returns the lock used for writing.
*
* @return the lock used for writing
*/
Lock writeLock();