Java java.util.concurrent.locks 类 ReentrantReadWriteLock（JDK5）

所有类

概述  软件包   类  使用  树  已过时  索引  帮助
摘要： 嵌套 | 字段 | 构造方法 | 方法	详细信息： 字段 | 构造方法 | 方法

---

java.util.concurrent.locks
类 ReentrantReadWriteLock

java.lang.Object
  java.util.concurrent.locks.ReentrantReadWriteLock

所有已实现的接口：

Serializable, ReadWriteLock

---

public class ReentrantReadWriteLock
   
   
   
   
   
extends Object
   
   
   
   
   
   
   
   
   
   
implements ReadWriteLock, Serializable
   
   
   
   
   

支持与 ReentrantLock 类似语义的 ReadWriteLock 实现。

此类具有以下属性：

• 获取顺序

  此类不会将读取者优先或写入者优先强加给锁定访问的排序。但是，它确实支持可选的公平 策略。当公平地构造线程时，线程利用一个近似到达顺序的策略来争夺进入。当释放写入锁定后，将写入锁定分配给等待时间最长的单个写入者，如果有一个等待时间比所有写入者更长的读取者，则将读取锁定分配给读取者 set。当非公平地构造线程时，则不需要按照到达顺序进入锁定。不管是哪一种情况，如果读取者处于活动状态，而某个写入者进入锁定状态，那么在获取写入者并释放写入锁定之前，不会将读取锁定授予任何后续的读取者。

• 重入

  此锁定允许读取者和写入者按照 ReentrantLock 的样式重新获取读取锁定或写入锁定。在写入线程保持的所有写入锁定都已经释放后，才允许写入者使用它们。

  此外，写入者可以获取读取锁定——但反过来则不成立。在其他应用程序中，当在调用或回调那些在读取锁定状态下执行读取操作的方法期间保持写入锁定时，重入很有用。如果读取者试图获取写入锁定，那么将永远不会获得成功。

• 锁定降级

  重入还允许从写入锁定降级为读取锁定，其实现方式是：先获取写入锁定，然后获取读取锁定，最后释放写入锁定。但是，从读取锁定升级到写入锁定是不可能的。

• 锁定获取的中断

  读取锁定和写入锁定都支持锁定获取期间的中断。

• Condition 支持

  写入锁定提供了一个 Condition 实现，对于写入锁定来说，该实现的行为与 ReentrantLock.newCondition() 提供的 Condition 实现对 ReentrantLock 所做的行为相同。当然，此 Condition 只能用于写入锁定。

  读取锁定不支持 Condition，readLock().newCondition() 会抛出 UnsupportedOperationException。

• 监测

  此类支持一些确定是保持锁定还是争用锁定的方法。这些方法设计用于监视系统状态，而不是同步控制。

此类行为的序列化方式与内置锁定的相同：反序列化的锁定处于解除锁定状态，无论序列化该锁定时其状态如何。

示例用法。下面的代码展示了如何利用重入来执行升级缓存后的锁定降级（为简单起见，省略了异常处理）：

 class CachedData {
   Object data;
   volatile boolean cacheValid;
   ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();

   void processCachedData() {
     rwl.readLock().lock();
     if (!cacheValid) {
        // upgrade lock manually
        rwl.readLock().unlock();   // must unlock first to obtain writelock
        rwl.writeLock().lock();
        if (!cacheValid) { // recheck
          data = ...
          cacheValid = true;
        }
        // downgrade lock
        rwl.readLock().lock();  // reacquire read without giving up write lock
        rwl.writeLock().unlock(); // unlock write, still hold read
     }

     use(data);
     rwl.readLock().unlock();
   }
 }
 

在使用某些种类的 Collection 时，可以使用 ReentrantReadWriteLock 来提高并发性。通常，在预期 collection 很大，读取者线程访问它的次数多于写入者线程，并且 entail 操作的开销高于同步开销时，这很值得一试。例如，以下是一个使用 TreeMap 的类，预期它很大，并且能被同时访问。

 class RWDictionary {
    private final Map<String, Data>  m = new TreeMap<String, Data>();
    private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock();
    private final Lock r = rwl.readLock();
    private final Lock w = rwl.writeLock();

    public Data get(String key) {
        r.lock(); try { return m.get(key); } finally { r.unlock(); }
    }
    public String[] allKeys() {
        r.lock(); try { return m.keySet().toArray(); } finally { r.unlock(); }
    }
    public Data put(String key, Data value) {
        w.lock(); try { return m.put(key, value); } finally { w.unlock(); }
    }
    public void clear() {
        w.lock(); try { m.clear(); } finally { w.unlock(); }
    }
 }
 

实现注意事项：

重入写入锁定定义了一个所有者，但只有获取它的线程才能将它释放。相反，在此实现中，读取锁定没有所有权这一概念，并不要求释放读取锁定的线程与获取该锁定的线程是同一线程。但是，无法保证此类以后的实现中会保持此属性。

此锁定最多支持 65536 个递归写入锁定和 65536 个读取锁定。试图超出这些限制将导致锁定方法抛出 Error。

从以下版本开始：

1.5

另请参见：

序列化表格

---

嵌套类摘要
static class	ReentrantReadWriteLock.ReadLock           readLock() 方法返回的锁定。
static class	ReentrantReadWriteLock.WriteLock           writeLock() 方法返回的锁定。

 

构造方法摘要
ReentrantReadWriteLock()           使用默认的排序属性创建一个新的 ReentrantReadWriteLock。
ReentrantReadWriteLock(boolean fair)           使用给定的公平策略创建一个新的 ReentrantReadWriteLock。

 

方法摘要
protected  Thread	getOwner()           返回当前拥有写入锁定的线程，如果没有这样的线程，则返回 null。
protected  Collection<Thread>	getQueuedReaderThreads()           返回一个 collection，它包含可能正在等待获取读取锁定的线程。
protected  Collection<Thread>	getQueuedThreads()           返回一个 collection，它包含可能正在等待获取读取或写入锁定的线程。
protected  Collection<Thread>	getQueuedWriterThreads()           返回一个 collection，它包含可能正在等待获取写入锁定的线程。
int	getQueueLength()           返回等待获取读取或写入锁定的线程估计数目。
int	getReadLockCount()           查询为此锁定保持的读取锁定数量。
protected  Collection<Thread>	getWaitingThreads(Condition condition)           返回一个 collection，它包含可能正在等待与写入锁定相关的给定条件的那些线程。
int	getWaitQueueLength(Condition condition)           返回正等待与写入锁定相关的给定条件的线程估计数目。
int	getWriteHoldCount()           查询当前线程在此锁定上保持的重入写入锁定数量。
boolean	hasQueuedThread(Thread thread)           查询是否给定线程正在等待获取读取或写入锁定。
boolean	hasQueuedThreads()           查询是否所有的线程正在等待获取读取或写入锁定。
boolean	hasWaiters(Condition condition)           查询是否有些线程正在等待与写入锁定有关的给定条件。
boolean	isFair()           如果此锁定将公平性设置为 ture，则返回 ture。
boolean	isWriteLocked()           查询是否某个线程保持了写入锁定。
boolean	isWriteLockedByCurrentThread()           查询当前线程是否保持了写入锁定。
ReentrantReadWriteLock.ReadLock	readLock()           返回用于读取操作的锁定。
String	toString()           返回标识此锁定及其锁定状态的字符串。
ReentrantReadWriteLock.WriteLock	writeLock()           返回用于写入操作的锁定。

 

从类 java.lang.Object 继承的方法
clone, equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait

 

构造方法详细信息

ReentrantReadWriteLock

public ReentrantReadWriteLock()

使用默认的排序属性创建一个新的 ReentrantReadWriteLock。

---

ReentrantReadWriteLock

public ReentrantReadWriteLock(boolean fair)

使用给定的公平策略创建一个新的 ReentrantReadWriteLock。

参数：

fair - 如果此锁定应该使用公平排序策略，则该参数的值为 ture

方法详细信息

writeLock

public ReentrantReadWriteLock.WriteLock writeLock()

从接口 ReadWriteLock 复制的描述

返回用于写入操作的锁定。

指定者：

接口 ReadWriteLock 中的 writeLock

返回：

用于写入操作的锁定。

---

readLock

public ReentrantReadWriteLock.ReadLock readLock()

从接口 ReadWriteLock 复制的描述

返回用于读取操作的锁定。

指定者：

接口 ReadWriteLock 中的 readLock

返回：

用于读取操作的锁定。

---

isFair

public final boolean isFair()

如果此锁定将公平性设置为 ture，则返回 ture。

返回：

如果此锁定将公平性设置为 ture，则返回 ture。

---

getOwner

protected Thread getOwner()

返回当前拥有写入锁定的线程，如果没有这样的线程，则返回 null。注意，即使存在试图获取锁定的线程，但是在它还没有获取前，所有者可能暂时为 null。设计此方法是为了便于构造提供更多扩展的锁定监视器设施的子类。

返回：

所有者，如果没有所有者，则返回 null。

---

getReadLockCount

public int getReadLockCount()

查询为此锁定保持的读取锁定数量。此方法设计用于监视系统状态，而不是同步控制。

返回：

所保持的读取锁定数量。

---

isWriteLocked

public boolean isWriteLocked()

查询是否某个线程保持了写入锁定。此方法设计用于监视系统状态，而不是同步控制。

返回：

如果某个线程保持写入锁定，则返回 true；否则返回 false。