ReeantrantReadWriteLock中的公平锁定

Question

在B.Goetz在实践中的Java并发性中，第13.5节说：

在Java5.0中，读锁的行为更像信号量而不是锁，只保持活动读取器的计数，而不是它们的身份。该行为在Java6中被更改，以跟踪哪些线程已被授予读lock6。 6进行此更改的一个原因是，在java5.0中，锁实现不能区分首次请求读锁的线程和重入的锁请求，这将使公平地读写锁死锁。

我的问题是公平有什么问题？为什么不公平的读写锁不受死锁的影响？

你能解释一下他的意思吗？我的意思是，在何种情况下，公平的Java5下的读写锁会导致死锁？如果它表现得像一个Semaphore，那么为什么公平的Semaphore没有导致死锁呢？

Answer 1

如果实现不知道请求线程是否已经拥有锁，则在公平锁定策略的情况下，来自同一线程的新请求将在先前的请求之后排队，可能来自其他线程。

如果在这个重入请求之前有来自其他线程的写请求，它们就不能前进，因为持有锁的线程也会被阻塞，等待它的重入请求。导致僵局。

不公平的锁定策略不受此问题的影响，因为重入请求可以跳出队列(驳船)，并且不需要等待先前的请求。

信号量不受这个问题的影响，因为它不是要重入的。