Java ReentrantLock 怎样使用公平锁模式

创建 new ReentrantLock(true) 就能启用公平锁模式。在存在竞争时，它倾向于让等待时间最长的线程先获得锁。使用时仍要让共享状态对应同一把锁，并把 unlock() 放在成功获锁之后的 finally 中；公平策略不会替你完成资源释放。

官方 API 地址：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/concurrent/locks/ReentrantLock.html。最小配置如下，这是类字段片段：

import java.util.concurrent.locks.ReentrantLock;

// true 启用公平策略；同一份共享状态要使用同一把锁
private final ReentrantLock lock = new ReentrantLock(true);

用构造参数启用公平策略

公平性在构造锁时指定。无参构造器等价于传入 false；true 表示选择公平排序策略。它是已有的 Java 并发能力，本文不把它描述成某个版本刚发布的新功能。

锁的策略与共享状态的归属要一起考虑。如果每次调用方法都临时 new 一把锁，不同线程就可能锁住不同对象，无法保护同一份状态。通常把它放在拥有共享字段的对象中，并保持字段引用稳定。

适合关注等待分布的共享状态

假设一个箱件计数对象被多个工作线程共享，线程需要短时间进入临界区更新 count。若团队关注竞争时的等待分布，而不是只追求单位时间内的操作次数，可以把公平锁作为一个比较选项。

这里的“公平”约束的是锁竞争中的准入策略，不是业务任务的整体先后顺序。线程可能在到达锁之前经历不同调度，也可能持锁时间不同。若要求严格按业务单号、消息到达次序执行，单独给锁加 true 并不能建立那种顺序契约。

对于没有实际竞争的代码，不应仅凭名称就默认公平锁一定更合适。先确认共享状态和临界区确实存在，再决定是否需要改变等待策略。

以同一把锁保护完整临界区

下面给出一个独立类。addOne 使用普通阻塞获取；snapshot 使用同一把锁读取；tryAdd 给调用者一个有限等待入口。代码用于解释获取、访问与释放的对应关系，本文未运行并发测试。

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

public final class ParcelCounter {
    private final ReentrantLock lock = new ReentrantLock(true);
    private int count;

    public void addOne() {
        lock.lock();
        try {
            // 更新共享状态，不在锁内执行网络或磁盘操作
            count++;
        } finally {
            // 即使临界区抛出异常，也释放本次持有
            lock.unlock();
        }
    }

    public int snapshot() {
        lock.lock();
        try {
            // 读取与更新使用同一把锁
            return count;
        } finally {
            lock.unlock();
        }
    }

    public boolean tryAdd(long waitMillis) throws InterruptedException {
        // 示例接口拒绝负等待值，单位在调用处固定为毫秒
        if (waitMillis 

tryAdd 返回 false 表示等待时间内未获得锁，所以没有任何业务更新。InterruptedException 直接交给上层处理；它与“等到超时”不同，不在这里合并成 false。调用者应按自己的取消协议决定如何响应中断。

只有获取成功才进入 try/finally。把获取失败与释放混在一起，可能在当前线程没有持有锁时调用 unlock。示例也没有把网络请求、文件写入等耗时动作放进临界区；持锁时间变长时，即使选择公平策略，后面的线程仍然需要等待。

可重入意味着当前持有线程能够再次获得同一把锁。每次成功获取都要有对应释放；公平策略不会取消这种重入语义。

与默认锁及两种 tryLock 比较

一个常见误区是在公平锁外再写一个不断调用无参 tryLock 的循环，希望“更积极地排队”。无参方法本身不遵守公平设置，循环也不自动形成有序等待。是否需要立即尝试、可中断等待或有限等待，应直接通过合适的方法表达。

如果不希望等待、同时又要尊重公平设置，官方 API 指出可以使用带单位的零超时尝试，例如 tryLock(0, TimeUnit.SECONDS)。它还会检测中断，因此不能把它与无参形式当成完全相同的方法。

采用前明确吞吐与调度边界

公平锁可能降低高竞争场景的整体吞吐量，而等待时间的离散程度可能更小。是否值得切换，需要结合线程数量、临界区长度和实际负载评估，不能根据一段固定线程打印顺序就下结论。本文没有提供性能倍数或运行顺序证明。

锁公平也不保证操作系统或 JVM 的线程调度公平。某个线程可能连续获得锁，而其他活跃线程尚未得到运行机会。它不承诺每个线程在一个固定毫秒数内必定获得锁，也不能自动消除多把锁之间的死锁。

排查时可以区分配置、使用与观测：isFair 表示锁的配置；代码是否始终使用同一实例、是否存在绕过公平策略的无参尝试，属于使用方式；等待时间和队列长度则属于运行观测。getQueueLength 返回估计值，不应把它作为业务同步条件。

计数器例子只表达锁的使用，未覆盖整数溢出或业务取消后的重试规则。迁移到真实服务时，应继续保留业务自身的数值范围、超时和取消约定。

公平锁能保证线程按启动顺序执行吗？

不能。线程启动、调度和到达锁的位置不等同于实际等待关系，公平策略也不等于任务调度器。

为什么 fair=true 后仍看到新线程先获锁？

先看是否使用了无参 tryLock，再区分线程日志顺序、实际等待状态和调度时机；不要只用一段打印顺序推断策略失效。

超时或中断后还要 unlock 吗？

本例没有成功获得锁时不释放；获得成功之后才通过 finally 释放本次持有。

依据：ReentrantLock 官方 API，包括构造器、tryLock 重载与监测方法说明。