为什么在 ReentrantReadWriteLock 中，readLock() 应该在 writeLock().lock() 之前解锁？

Question

来自ReentrantReadWriteLock class javadoc：

void processCachedData() {
  rwl.readLock().lock();
  if (!cacheValid) {
     // Must release read lock before acquiring write lock
5:   rwl.readLock().unlock();
6:   rwl.writeLock().lock();
     // Recheck state because another thread might have acquired
     //   write lock and changed state before we did.
     if (!cacheValid) {
       data = ...
       cacheValid = true;
     }
     // Downgrade by acquiring read lock before releasing write lock
14:  rwl.readLock().lock();
15:  rwl.writeLock().unlock(); // Unlock write, still hold read
  }

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

为什么我们必须在获得评论中写的写锁之前释放读锁？如果当前线程持有读锁，那么无论当前线程是否也持有读锁，都应该允许在其他线程不再读取时获取写锁。这是我所期望的行为。

我希望第 5 行和第 6 行的锁升级和第 14 行和第 15 行的锁降级在 ReentrantReadWriteLock 类内部完成。为什么这不可能？

换句话说，我希望代码可以像这样正常工作：

void processCachedData() {
  rwl.readLock().lock();
  if (!cacheValid) {
     // The readlock is upgraded to writeLock when other threads 
     // release their readlocks.
     rwl.writeLock().lock();
     // no need to recheck: other threads can't have acquired  
     // the write lock since this thread still holds also the readLock!!!
     if (!cacheValid) {  
       data = ...
       cacheValid = true;
     }
     // Downgrade by acquiring read lock before releasing write lock
     rwl.writeLock().unlock(); // Unlock write, still hold read
  }

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

这看起来是一种更好、更安全的处理锁定方式，不是吗？

有人可以解释这种奇怪实现的原因吗？谢谢。

Answer 1

将读锁升级为写锁的问题是，如果两个线程同时尝试这样做，可能会导致死锁。考虑以下顺序：

1. 线程 A：获取读锁
2. 线程 B：获取读锁（请注意，两个线程现在共享读锁）。
3. 线程 A：尝试获取写锁（线程 B 持有读锁时阻塞）
4. 线程 B：尝试获取写锁（线程 A 持有读锁时阻塞）

现在出现了死锁。线程 A 或 B 都不能继续，也永远不会释放读锁。

Answer 2

Javadoc 明确指出不可能将读锁升级为写锁。 原因是因为它会造成死锁。

• 线程 1 获取读锁
• 线程 2 获取读锁
• 线程1要求升级锁写
• 线程2要求升级锁写

两个线程现在都在互相等待……永远。

Answer 3

可重入允许从写锁降级为读锁，方法是获取写锁，然后是读锁，然后释放写锁。但是，无法从读锁升级到写锁（这会导致死锁）。

来源：http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html