Java 不公平锁如何比公平锁具有更好的性能？

接口锁有一个有用的布尔公平性参数来保证锁的公平性-等待锁最长的线程首先获得锁。我想我想在任何地方都使用它，因为它可以防止饥饿。嗯，在我读到它会影响我们的表现之前

---

我找不到这个问题的答案，所以我希望有人能澄清这一点。意思是，接受“尊重”公平的线程和不尊重公平的线程有什么区别？它们不是都存储在其他等待线程所在的“普通”队列中吗？

首先，具有公平性的不是

接口锁，而是
可重入锁

发出
Lock:：Lock
的线程可能根本不会被放入队列中，无论是处于
fair
模式还是
fair
模式

模式更容易理解。在此模式下，请求锁的线程（通过调用
lock:：lock
）尝试立即获取锁，而不排队。如果成功，那么就完成。它不会被放入任何队列，因为它可以获得锁。请注意，这并不关心队列中是否已经有等待的线程，因此这是“不公平的”（对其他已经等待的线程）。如果它无法获取锁（意味着其他人拥有它），它将被放入队列中

另一方面，在
fair
模式下，调用
lock
的线程首先必须检查是否已经有线程等待此锁。如果没有这样的线程，它可以获取锁：no排队并获取锁。如果不能，它将被排队

最后一点是，在公平和不公平模式下，线程都放在同一队列上；也就是说：
公平/不公平
与队列的内部表示无关。
当一个锁被释放，并且有多个线程在等待它时，等待时间最长的线程最有可能发现它想要的内存页在“睡眠”时被调出睡眠时间最少的线程最有可能“准备就绪”


如果你想说的话，请向@邢彬道歉。
你需要考虑操作系统在选择线程执行时应用算法。它不是随机选择，它的实现当然更智能。通过使用公平锁定，操作系统将绕过这些优化。我确信你也在绕过JVM的优化。Re，“…它必须是一个允许随机访问的数据结构，”是的，但不管调度程序一直等待线程的容器的实际形状如何，每个人都称它们为“队列”。@SolomonSlow是的，在你指出这一点之前，我没有注意到这一点。非常感谢。