10

ReadWriteLock实现允许降级ReentrantReadWriteLock（tryLock()从下面的示例中总是返回true）：

void downgrade(final ReadWriteLock readWriteLock) {
    boolean downgraded = false;
    readWriteLock.writeLock().lock();
    try {
        // Always true, as we already hold a W lock.
        final boolean readLockAcquired = readWriteLock.readLock().tryLock();
        if (readLockAcquired) {
            // Now holding both a R and a W lock.
            assert ((ReentrantReadWriteLock) readWriteLock).getReadHoldCount() == 1;
            assert ((ReentrantReadWriteLock) readWriteLock).getWriteHoldCount() == 1;

            readWriteLock.writeLock().unlock();
            downgraded = true;
            try {
                // Now do some work with only a R lock held
            } finally {
                readWriteLock.readLock().unlock();

                assert ((ReentrantReadWriteLock) readWriteLock).getReadHoldCount() == 0;
                assert ((ReentrantReadWriteLock) readWriteLock).getWriteHoldCount() == 0;
            }
        }
    } finally {
        if (!downgraded) {
            // Never (we were holding a W lock while trying a R lock).
            readWriteLock.writeLock().unlock();
        }
        assert ((ReentrantReadWriteLock) readWriteLock).getReadHoldCount() == 0;
        assert ((ReentrantReadWriteLock) readWriteLock).getWriteHoldCount() == 0;
    }
}

不允许以类似方式升级锁的想法是什么？在没有其他线程持有读锁的情况下，下面的写tryLock()锁方法可以安全地返回无死锁风险：true

void upgrade(final ReadWriteLock readWriteLock) {
    readWriteLock.readLock().lock();
    try {
        // Always false: lock upgrade is not allowed
        final boolean writeLockAcquired = readWriteLock.writeLock().tryLock();
        // ...
    } finally {
        readWriteLock.readLock().unlock();
    }
}
4

1 回答 1

6

首先，让我们注意升级和降级在ReadWriteLocks 的语义复杂度方面是不等价的。

您不需要避免争用来完成降级事务，因为您已经拥有对锁的升级最多的权限，并且保证您是当前执行降级的唯一线程。升级并非如此，因此支持升级的机制自然需要更复杂（或更智能）。

为了可用，升级机制需要防止死锁，以防两个读取线程同时尝试升级（或专门用于ReentrantReadWriteLock，以防持有多个读取锁的单个读取线程尝试升级）。此外，该机制需要指定如何处理失败的升级请求（其读锁是否会失效），而这更不重要。

正如您现在可能看到的ReentrantReadWriteLock那样，至少可以说完全处理这些问题是不方便的（不过，这是 .NET 的ReaderWriterLock尝试，我认为实际上是成功的）。我的猜测是，虽然final boolean writeLockAcquired = readWriteLock.writeLock().tryLock();可以在一些微不足道的情况下取得成功，但可升级性仍然不足以供普通使用 - 在足够激烈的争用下，如果你输掉了写锁的竞争，你也是一样就像你解锁了读锁并试图获得写锁一样（让其他人有机会潜入并在中间获取写锁）。

提供锁可升级性的一个好方法是只允许单个线程尝试升级——这就是ReentrantReadWriteUpdateLock.NET 所做的或所做的ReaderWriterLockSlim。但是我仍然会推荐 Java 8 StampedLock：

  • 在低竞争下，它的乐观读取比使用读锁快得多
  • 它的 API 对升级的限制要小得多（从乐观读到读锁再到写锁）
  • 我各种尝试创建一个现实的 JMH 基准测试，其中一个类似的锁击败它几乎总是失败
于 2016-04-11T23:09:00.177 回答