考虑这个 JDK 标准接口(interface):
public interface ReadWriteLock{
public Lock readLock();
public Lock writeLock();
}
B. Goetz 在 Java Concurrency 实践中提到从 readLock 升级到 writeLock 容易死锁。
让我感到困惑的是，是 两个 读者试图升级。但即使一位读者就足够了，不是吗？如果读取器尝试升级，则尚未释放读取锁。试图在持有读锁的情况下获取写锁是死锁的。
因此，从这一点来看，我认为提供升级操作在理论上甚至是荒谬的。或者也许一个实现可以解决这个问题？
最佳答案
听起来您正在考虑将“读锁”和“写锁”视为构成读写锁的两个不同锁。这不是正确的思考方式，即使 API 似乎公开了这样的组合(通过提供方法来获取对“写锁”和“读锁”的引用)。
(这一切都被术语“锁”的重载所混淆——它既是动词又是名词，即可以锁定一把锁)。
与其认为 ReadWriteLock 的 readLock 方法和 writeLock 方法返回实际锁，不如考虑它们实际做的是返回一个抽象机制，允许获取不同类型的锁(在相同的、单一的、读写锁机制上)。
读写锁(机制)是一个单一的锁，可以通过两种方式锁定:读锁定和写锁定。读写锁可以被一个或多个线程并发读锁，也可以被写锁。它永远不能同时被读和写锁定。
写锁比读锁强；它就像一个带有附加属性的读锁(没有其他线程也可以持有该锁)。从读锁升级到写锁并不是在已经持有另一个锁时获取另一个锁；相反，它是关于更改已持有在单个锁上的锁的类型。
因此，单线程将其读锁升级为写锁不存在概念上的问题；它只需要等待读锁的所有其他持有者在升级发生之前放弃它。在这种情况下不存在死锁的可能性。
例如，假设有三个线程——A、B 和 C，它们都对锁进行了读锁定。线程 A 尝试升级到写锁。这意味着它必须等待 B 和 C 放弃他们的读锁。这最终会发生，此时线程 A 获得了一个写锁(并且，最终，线程 A 将放弃这个锁)。
另一方面，考虑 A 和 B 是否都尝试升级到写锁。这意味着他们都在等待另一个放弃读锁，这不会发生；对于线程 A 放弃读锁，它首先需要获取写锁，直到线程 B 放弃读锁才会发生这种情况，直到它获得写锁才会发生这种情况，这不会发生直到线程 A 放弃读锁……依此类推。有一个僵局。
Java API 不允许从读锁升级到写锁，因为这可以防止死锁情况。编写一个可以安全升级锁类型的程序是可能的(如果有点棘手)，但无论如何 Java API 都不允许这样做。
关于java - 读写锁。了解从 readLock 升级到 writeLock，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/37087120/