0

ReentrantReadWriteLock我有一些密切相关的问题在尝试使用来控制对具有许多不同读写操作的相当复杂的数据结构的访问时弹出。根据文档中的示例，我已经获取了一个读取和写入锁，并且我正在使用它们（据我所知）成功管理对该数据结构的并发访问。然而，在调试另一个问题时，我注意到有时我在同一个线程中获得了多个读锁。其基本原因是我有许多复杂的查询会调用更简单的查询（请参见下面的示例）。复杂的查询可以被认为是一个事务，即在和对ingetVersion()的访问之间不应该有写操作。datamyQuery. 这个当前的解决方案有效，但这意味着在代码中的某些地方，我将拥有同一个线程拥有的多个读锁。我注意到 write 等价物有一个isHeldByCurrentThread()方法，但奇怪的是在readLock. 我找不到以下内容：

  • 在同一个线程中有多个读锁是不是很糟糕（糟糕的风格、性能或未来错误的风险）？
  • is 不适合用于WriteLock.isHeldByCurrentThread检查错误（例如，期望写入锁但不存在，或者作为释放写入锁的条件）？
  • 如果这是一个问题，是否有最佳实践来决定如何进行？我是否将lockedAquired布尔值传递给可能从已经拥有锁的代码中调用的方法，我是否确保它们是唯一获取的，还是应该使用ReadLock.tryLock()？

这是代码示例：

public class GraphWorldModel {

  //unfair RW Lock (default, see javadoc)
  protected final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(false);
  protected final ReentrantReadWriteLock.ReadLock readLock = rwl.readLock();
  protected final ReentrantReadWriteLock.WriteLock writeLock = rwl.writeLock();

  protected long versionID = 0;
  protected Object data = null;

  @Override
  public long getVersion() {
      long result = -1;
      readLock.lock();
      try {
          result = this.versionID;
      } finally {

          readLock.unlock();
      }
      return result;
  }
  public ResultObject myQuery() {
      //do some work
      readLock.lock();
      try {
        long version = getVersion();
        ResultObject result = new ResultObject(this.data, version);
        //note: querying version and result should be atomic!
      } finally {
        readLock.unlock();
      }
      //do some more work
      return result;
  }
}
4

1 回答 1

1
  • 在同一个线程中有多个读锁是不是很糟糕（糟糕的风格、性能或未来错误的风险）？

我会说这是有问题的风格。首先，正如@JBNizet 指出的那样，您尝试再次获取您已经拥有的锁没有问题。锁只是将阅读器计数增加一，然后在最终解锁时减少它。

但是，这确实意味着您必须跨越内存屏障（volatile读取）来更新共享锁统计信息，这意味着性能下降。这取决于此代码执行的频率是否会产生任何明显的性能差异。

然而，就错误而言，有一个很大的问题。如果您只是在谈论只读锁，那么我认为不会有更多的错误机会。实际上试图解决双锁问题（见下文）可能有更大的风险。但是在您的代码中，try/finally 逻辑可确保正确使用锁并在完成时解锁。

但是，如果您在谈论混合读写锁，那么您需要了解以下代码死锁：

ReentrantReadWriteLock rrwl = new ReentrantReadWriteLock();
ReadLock readLock = rrwl.readLock();
WriteLock writeLock = rrwl.writeLock();
readLock.lock();
writeLock.lock();

或者至少它会停止，直到其他一些代码解锁read-lock. 如果要在代码中混合读写锁，则必须防止双重锁定。

  • 使用WriteLock.isHeldByCurrentThread 来检查错误是不好的（例如，期望写锁但不存在，或者作为释放写锁的条件）？

这将为您的代码添加大量逻辑，这风险更大，但如果性能影响很大，则可能值得。也就是说，请参阅下面的替代方案。

  • 如果这是一个问题，是否有最佳实践来决定如何进行？我是否将lockedAquired 布尔值传递给可能从已经拥有锁的代码中调用的方法，我是否确保它们是唯一获取的，还是应该使用ReadLock.tryLock()？

我要做的是创建一个名为getVersionLocked(). 就像是：

@Override
public long getVersion() {
    readLock.lock();
    try {
        // NOTE: I refactored this to return out of the try/finally which is a fine pattern
        return getVersionLocked();
    } finally {
        readLock.unlock();
    }
}
public ResultObject myQuery() {
    //do some work
    readLock.lock();
    ResultObject result;
    try {
      long version = getVersionLocked();
      result = new ResultObject(this.data, version);
      //note: querying version and result should be atomic!
    } finally {
      readLock.unlock();
    }
    //do some more work
    return result;
}
// NOTE: to call this method, we must already be locked
private long getVersionLocked() {
    return this.versionID;
}

然后，您可以决定调用方法的锁定或解锁版本，并且只执行readLock()一次。

这风险更大，因为您可能会在未getVersionLocked()持有锁时调用，但我认为这是可以接受的风险。

于 2016-12-13T23:53:07.023 回答