JAVA中REENTRANT LOCK中公平参数的目的是什么？

Question

我在浏览可重入锁的Java文档时发现了以下文字：

锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的许多线程之一可能会连续多次获得它，而其他活动线程没有进展并且当前没有持有锁。

根据我的理解，这意味着，如果操作系统调度程序调度相同的线程（之前获取锁）并尝试再次获取相同的锁，Java 将允许它获取并且不会遵守公平参数值.有人可以告诉我们公平参数的目的是什么以及应该在什么情况下使用它。
我只是在想它是否只是一个优先级值，这可能会影响调度程序但不能保证线程执行顺序。

Answer 1

在幼稚的观点中，使用公平锁的线程的行为会像

Thread 1	Thread 2	Thread 3
Acquire	Do something	Do something
Critical Section	Try Acquire	Do something
Critical Section	Blocked	Try Acquire
Release	Acquire	Blocked
Do something	Critical Section	Blocked
Try Acquire	Release	Acquire
Blocked	Do something	Critical Section
Acquire	Do something	Release

“Try Acquire”是指对lock() 的调用，它不会立即成功，因为另一个线程拥有锁。它不是指tryLock()，这通常是不公平的。

在这种幼稚的观点中，线程按“线程 1”、“线程 2”、“线程 3”的顺序获取锁，因为这是获取尝试的顺序。尤其是当“线程 1”试图在“线程 2”释放它的同时立即获取锁时，它不会像不公平锁那样超过，而是“线程 3”得到它，因为它等待的时间更长。

但是，正如文档所说，线程调度是不公平的。所以可能会发生以下情况。

Thread 1	Thread 2	Thread 3
Acquire	Do something	Do something
Critical Section		Do something
Critical Section
Release
Do something
Acquire	Try Acquire	Try Acquire
Critical Section	Blocked	Blocked
Critical Section	Blocked	Blocked

空单元格表示线程根本没有获得任何 CPU 时间的阶段。线程可能比 CPU 内核多，其中包括其他进程的线程。操作系统甚至可能更愿意让“线程 1”在内核上继续运行，而不是切换到其他线程，这仅仅是因为该线程已经运行并且切换需要时间。

一般来说，尝试预测到达某个点的相对时间（如前面的工作负载获取锁）并不是一个好主意。在具有优化 JIT 编译器的环境中，即使是两个线程在完全相同的输入下执行完全相同的代码也可能具有完全不同的执行时间。

因此，当我们无法预测 lock() 尝试的时间时，坚持以不可预测的未知顺序获取锁并不是很有用。开发人员仍然希望公平的一种解释是，即使结果顺序不可预测，它也应该确保每个线程都取得进展，而不是在其他线程反复超车时无限等待锁。但这让我们回到了不公平的线程调度；即使根本没有锁，也不能保证所有线程都会进行。

那么为什么公平选项仍然存在？因为有时，人们对它在大多数情况下的工作方式感到满意，即使没有强有力的保证它会一直以这种方式工作。或者简单地说，因为如果它不存在，开发人员会反复要求它。支持公平的成本并不高，也不会影响不公平锁的性能。

Answer 2

锁的公平性并不能保证线程调度的公平性。因此，使用公平锁的许多线程之一可能会连续多次获得它，而其他活动线程没有进展并且当前没有持有锁。

我将“没有进展”解释为“没有进展的原因与所讨论的锁定无关。”我认为他们试图告诉你“公平”仅在以下情况下才有意义锁的竞争非常激烈，以至于经常有一个或多个线程在等待轮到它们来锁定它。

如果线程 T 释放当前没有其他线程正在等待的“公平”锁，那么“公平”不会影响下一个线程将获得它。这只是线程之间的直接竞赛，由 OS 调度程序主持。

只有当多个线程在等待时，一个公平的锁才应该“支持”等待时间最长的那个。特别是，我希望如果某个线程 T 释放了其他线程正在等待的“公平”锁，然后线程 T 立即尝试再次锁定它，那么lock() 函数会注意到其他正在等待的线程，并将 T 发送到队列的后面。

但是，我实际上并不知道它是如何在任何特定的 JVM 中实现的。

---

P.S.，IMO，“公平”就像绷带，可以止血复合骨折。如果您的程序有一个竞争激烈的锁，以至于“公平”会产生任何影响，那么这是一个严重的设计缺陷。

The same Javadoc 还说，

使用由许多线程访问的公平锁的程序可能会显示出比使用默认设置的程序更低的整体吞吐量（即，速度较慢；通常要慢得多）。

Answer 3

ReentrantLock 是基于 AbstractQueuedSynchronizer 实现的，这是一个先进先出 (FIFO) 等待队列。

假设A、B、C三个线程依次尝试获取锁，A获取了锁，那么B、C会转化为AbstractQueuedSynchronizer#Node进入队列。这两个线程将被挂起。

当A线程释放锁时，会唤醒其后继节点（AbstractQueuedSynchronizer#unparkSuccessor），即线程B。线程B被唤醒后会再次尝试获取锁。

假设当B线程被唤醒时，突然有一个D线程来尝试获取这个锁。对于公平锁，D线程看到队列中还有其他节点在等待获取锁（AbstractQueuedSynchronizer#hasQueuedPredecessors），直接挂掉。

而且对于不公平锁，D线程会立即尝试获取这个锁，这意味着它可以尝试“跳队列”一次。如果这次“队列跳转”成功，那么可以立即获取锁（这意味着节点B将再次被挂起：它在与D线程的竞争中输了，它被切线了）。如果失败则挂起，作为Node进入队列。

为什么不公平锁表现更好以及何时使用公平锁？

这是来自Java-Concurrency-Practice：

在激烈争用的情况下，插入锁比公平锁性能好得多的一个原因是，在暂停的线程恢复和实际运行之间可能存在显着延迟。假设线程 A 持有一个锁，而线程 B 请求该锁。由于锁忙，B被挂起。当 A 释放锁时，B 会恢复，以便再次尝试。同时，如果线程 C 请求锁，C 很有可能在 B 完成唤醒之前获取锁、使用它并释放它。在这种情况下，每个人都会获胜：B 获得锁的时间不会晚于其他情况，C 获得锁的时间要早​​得多，并且吞吐量得到了提高。

公平的锁在持有时间相对较长时往往效果最佳 时间或锁定请求之间的平均时间相对较长时。 在这些情况下，驳船提供 吞吐量优势 - 当锁未被持有但线程被持有时 目前醒来声称它 - 不太可能持有。