java并发包concurrent翻译及源码分析之：ReadWriteLock

/* * ORACLE PROPRIETARY/CONFIDENTIAL. Use is subject to license terms. * * * * * * * * * * * * * * * * * * * * *//* * * * * * * Written by Doug Lea with assistance from members of JCP JSR-166 * Expert Group and released to the public domain, as explained at * http://creativecommons.org/publicdomain/zero/1.0/ */package java.util.concurrent.locks;/** * A <tt>ReadWriteLock</tt> 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. * 一个ReadWriteLock维护一对相关的锁，一个仅用于读操作的读锁，和另外一个仅用于写操作的写锁。 * 读锁可能被多个读线程同时拥有，只要没有写入者。写锁则是唯一的。 * * <p>All <tt>ReadWriteLock</tt> implementations must guarantee that * the memory synchronization effects of <tt>writeLock</tt> operations * (as specified in the {@link Lock} interface) also hold with respect * to the associated <tt>readLock</tt>. That is, a thread successfully * acquiring the read lock will see all updates made upon previous * release of the write lock. * 所有的ReadWriteLock实现者必须保证写锁操作对内存同步的影响也会被相关读锁所持有。 * 也就是说，一个成功获取读锁的线程将会看到先前版本写锁所做的所有更新。 * * <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 */public interface ReadWriteLock {    /**     * 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();}