非公平锁如何比公平锁有更好的性能呢？
How does unfair lock have better performance than fair lock?
接口 Lock 有一个有用的布尔公平参数来保证 fairness in locking - 等待锁时间最长的线程，最先获得锁。我想我想在任何地方都使用它，因为它可以防止 饥饿。好吧，在我读到它会降低我们的性能之前。
我找不到这个问题的答案，所以我希望有人能解决这个问题。意思是，采用“尊重”公平 的线程和不接受的线程有什么区别？它们不是都存储在其他等待线程所在的一些“普通”队列中吗？
首先，fairness 不是 interface Lock，而是 ReentrantLock。
发出Lock::lock的线程可能根本不会被放入队列，无论是在fair还是unfair模式下。
unfair模式稍微容易理解。在这种模式下，请求锁的线程（通过调用 Lock::lock）会尝试立即获取锁而不排队。如果成功 - 完成。它没有放入任何队列，因为它可以获得锁。请注意，这并不关心队列中是否已经有等待线程，因此它是“不公平的”（对其他已经等待的线程）。如果它无法获得锁（意味着其他人拥有它），它就会被放入队列中。
另一方面，在 fair 模式下，调用 lock 的线程首先必须检查是否已经有线程在等待这个锁。如果没有这样的线程并且它可以拿锁：没有入队并拿锁。如果不能 - 它被排队。
最后一点是，在both公平和非公平模式下，线程都放在同一个队列中；即：fair/unfair 与队列的内部表示无关。
当锁被释放时，当有多个线程在等待它时，等待最长的线程是最有可能找到该内存页的线程它正在“睡觉”时被换掉了。休眠时间最少的线程最有可能“准备就绪”。
向@xingbin 道歉，如果这就是你想说的。
接口 Lock 有一个有用的布尔公平参数来保证 fairness in locking - 等待锁时间最长的线程，最先获得锁。我想我想在任何地方都使用它，因为它可以防止 饥饿。好吧，在我读到它会降低我们的性能之前。
我找不到这个问题的答案，所以我希望有人能解决这个问题。意思是，采用“尊重”公平 的线程和不接受的线程有什么区别？它们不是都存储在其他等待线程所在的一些“普通”队列中吗？
首先，fairness 不是 interface Lock，而是 ReentrantLock。
发出Lock::lock的线程可能根本不会被放入队列，无论是在fair还是unfair模式下。
unfair模式稍微容易理解。在这种模式下，请求锁的线程（通过调用 Lock::lock）会尝试立即获取锁而不排队。如果成功 - 完成。它没有放入任何队列，因为它可以获得锁。请注意，这并不关心队列中是否已经有等待线程，因此它是“不公平的”（对其他已经等待的线程）。如果它无法获得锁（意味着其他人拥有它），它就会被放入队列中。
另一方面，在 fair 模式下，调用 lock 的线程首先必须检查是否已经有线程在等待这个锁。如果没有这样的线程并且它可以拿锁：没有入队并拿锁。如果不能 - 它被排队。
最后一点是，在both公平和非公平模式下，线程都放在同一个队列中；即：fair/unfair 与队列的内部表示无关。
当锁被释放时，当有多个线程在等待它时，等待最长的线程是最有可能找到该内存页的线程它正在“睡觉”时被换掉了。休眠时间最少的线程最有可能“准备就绪”。
向@xingbin 道歉，如果这就是你想说的。