Java ReentrantLock 公平锁为什么吞吐量更低

先给结论：new ReentrantLock(true) 会在竞争时优先照顾等待时间更长的线程，但它需要更严格地维护排队秩序，线程更难“趁锁空闲时直接插入”，因此高竞争下通常比默认的非公平锁吞吐量低。公平换来的是更稳定的等待时间和较低的饥饿风险，不是更快。

官方地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html

这里的比较只讨论同一把互斥锁、相同临界区和相同线程压力。公平锁也不能改变操作系统的线程调度；线程是否真的及时运行，仍由调度器决定。

如果业务更在意总完成量，先使用非公平锁并把临界区做短；如果排队请求不能长期得不到服务，再考虑公平锁。最终选择应由真实负载下的吞吐量、平均等待和尾延迟共同决定。

公平锁到底保证了什么

无参构造等价于非公平模式，访问顺序没有特定保证。传入 true 后，竞争中的锁会倾向于授予等待时间最长的线程。这个策略减少了某个线程连续被插队的机会，但“倾向”不是线程调度承诺，也不是严格的请求先来先服务队列。

非公平锁的优势在于锁刚释放时，正在运行的线程可能立即再次获取它，少一次排队和唤醒协调。公平锁需要尊重已有等待者，当前线程即使已经运行，也更可能先让出机会。竞争越激烈、临界区越短，这些协调成本在总耗时中的比例越明显。

因此，公平模式常见的收益是等待时间波动更小、饥饿风险更低；代价是上下文切换、线程唤醒和队列维护更频繁。吞吐下降并不表示数据错误，而是锁策略把一部分性能预算用在了服务顺序上。

用相同临界区做一个可比实验

比较时不要同时修改线程数、循环次数和业务代码。下面的示例只切换构造参数，所有线程都对同一个计数器执行相同长度的临界区；输出是示例格式，实际数字需要在目标机器上自行测量。

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.locks.ReentrantLock;

public class FairLockCompare {
    static long run(boolean fair, int workers, int rounds) throws InterruptedException {
        // 只改变公平参数，保证两组测试的临界区和工作量一致
        ReentrantLock lock = new ReentrantLock(fair);
        CountDownLatch start = new CountDownLatch(1);
        CountDownLatch done = new CountDownLatch(workers);
        long[] counter = {0};
        for (int i = 0; i  {
                try {
                    start.await(); // 同时放行，制造可比的竞争起点
                    for (int j = 0; j 

可以分别调用 run(false, 8, 200_000) 和 run(true, 8, 200_000)，重复多轮后比较每秒完成次数，而不是只看一次耗时。线程数较少或临界区较长时，差异可能不明显；线程数增加、竞争变密集且临界区很短时，公平模式的协调开销更容易显现。

两个容易误判的边界

第一，公平设置不会让所有线程严格轮流执行。线程拿到锁后可能被挂起，其他线程也可能还没获得运行机会，所以公平锁不能替代限流、调度或请求超时。

第二，无参的 tryLock() 不遵守公平设置：只要锁在调用瞬间可用，它就会立即成功，即使队列里已有等待线程。需要尊重公平策略时，可以使用带超时的形式，例如：

import java.util.concurrent.TimeUnit;

if (lock.tryLock(0, TimeUnit.SECONDS)) {
    try {
        // 中文说明：只在获得锁后访问共享状态
        updateSharedState();
    } finally {
        lock.unlock(); // 中文说明：在 finally 中释放锁，避免异常导致占用
    }
}

另外，锁内执行 I/O、网络请求或复杂计算，会让所有模式都变慢；先缩小临界区，通常比直接切换公平参数更有效。

怎么选才不会牺牲错性能

默认优先考虑非公平锁：它适合短临界区、吞吐优先、允许等待时间有波动的缓存更新、批处理或内部协调场景。公平锁更适合请求必须轮流得到机会、不能接受长期饥饿，且尾延迟稳定性比峰值吞吐更重要的场景。

不要用“公平一定好”或“非公平一定快”替代测量。至少固定并记录线程数、临界区内容、成功次数、平均等待、P95/P99 等指标；同时观察队列长度和业务超时。若公平锁吞吐下降但尾延迟明显改善，代价可能是值得的；若两者都没有改善，应回头检查锁粒度和共享状态设计。

常见问题

公平锁是不是严格 FIFO？

不是。它在竞争时倾向于照顾最长等待线程，但线程调度、重入和具体调用方式都会影响最终顺序。

为什么短临界区更容易看出吞吐差异？

临界区越短，真正处理数据的时间越少，排队、唤醒和调度协调成本占比越高，所以公平策略的代价更容易被放大。