ReeanTrandWriteLock中的公平锁定

Question

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

在Java5.0中，读锁的行为更像是一个信号量而不是锁，只维护活动读卡器的数量，而不是它们的身份。Java 6中的行为已更改，以跟踪哪些线程已被授予读锁6。

6这种变化的一个原因是，在java 5.0下，锁实现不能区分第一次请求读锁的线程和重入锁请求，这将使公平读写锁容易死锁。

我的问题是公平有什么问题？为什么不公平的读写锁会被死锁屏蔽？

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

Answer 1

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

如果在此重入请求之前有来自其他线程的写请求，则它们无法前进，因为持有锁的线程也被阻止等待其重入请求。导致僵局。

不公平的锁定策略不会遇到这个问题，因为可重入请求可以跳转队列（阻塞），并且不需要等待之前的请求。

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