不公平锁如何比公平锁有更好的性能？答案

【问题标题】：How does unfair lock have better performance than fair lock?不公平锁如何比公平锁有更好的性能？
【发布时间】：2020-11-25 01:56:14
【问题描述】：

接口Lock有一个有用的布尔公平参数来保证锁定中的公平 - 等待锁定时间最长的线程，得到先锁。我想我想在任何地方都使用它，因为它可以防止饥饿。好吧，在我读到它会降低我们的性能之前，不是这样。

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

【问题讨论】：

您需要考虑操作系统在选择执行线程时应用了算法。它不是随机选择，它当然更智能地实施。通过使用公平锁定，您绕过了操作系统的这些优化。我确定您也绕过了 JVM 的优化。

标签： java multithreading locking

【解决方案1】：

当一个锁被释放时，当多个线程在等待它时，等待时间最长的线程是最有可能找到它想要的内存页面的线程在它“睡觉”时被换掉了。休眠时间最短的线程最有可能“准备就绪”。

向@xingbin 道歉，如果这是您想说的话。

【讨论】：

【解决方案2】：

首先，拥有fairness 的不是interface Lock，而是ReentrantLock。

发出Lock::lock 的线程可能根本不会放入队列中，无论是fair 还是unfair 模式。

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

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

最后一点是，在两者公平和不公平模式下，线程被放在同一个队列中；即：fair/unfair 与队列的内部表示无关。

【讨论】：

Re，“...它必须是允许随机访问的数据结构，”是的，但无论调度程序保持等待线程的容器的实际形状如何，每个人都称它们为“队列” 。”
@SolomonSlow 是的，直到您指出这一点，我才注意到这一点。谢谢。