在B.Goetz的《Java Concurrency In Practice》第13.5节中提到:
在Java 5.0中,读锁更像一个信号量而不是锁,只维护活动读者的计数,而不是它们的身份。在Java 6中改变了这种行为,也跟踪了哪些线程已被授予读锁。这种变化的一个原因是,在Java 5.0下,锁实现无法区分请求第一次读锁和可重入锁请求的线程,这会使公平读写锁陷入死锁。
我的问题是:公平性有什么问题?为什么不公平的读写锁能够避免死锁?
您能解释一下他的意思吗?即在什么情况下,Java 5下的公平读写锁会导致死锁?如果它像一个Semaphore那样运作,为什么公平的Semaphore没有导致死锁?
在Java 5.0中,读锁更像一个信号量而不是锁,只维护活动读者的计数,而不是它们的身份。在Java 6中改变了这种行为,也跟踪了哪些线程已被授予读锁。这种变化的一个原因是,在Java 5.0下,锁实现无法区分请求第一次读锁和可重入锁请求的线程,这会使公平读写锁陷入死锁。
我的问题是:公平性有什么问题?为什么不公平的读写锁能够避免死锁?
您能解释一下他的意思吗?即在什么情况下,Java 5下的公平读写锁会导致死锁?如果它像一个Semaphore那样运作,为什么公平的Semaphore没有导致死锁?