Java ReentrantLock 公平锁怎么选：tryLock、超时与解锁边界

订单状态服务里有一段很短的库存回写逻辑：大多数请求只占锁几毫秒，偶尔却会因为下游重试把等待队列拖长。把 synchronized 换成 ReentrantLock 后，真正容易出错的并不是“会不会加锁”，而是公平参数、超时获取和异常路径有没有配成一套。

先把 ReentrantLock 的三个选择分开

ReentrantLock 的构造器只有一个关键开关：是否使用公平策略。默认的非公平锁吞吐量通常更高，但在竞争激烈时可能让等待线程持续排队；公平锁会更偏向等待时间长的线程，却可能牺牲整体吞吐。

这里还要分清两个经常被混在一起的概念：公平策略是锁的获取规则，线程调度是操作系统和 JVM 如何安排线程运行。前者不能承诺后者。

订单回写为什么更适合限时获取

假设同一订单只能被一个线程修改。无限等待看起来稳妥，却会把下游卡顿扩散到所有请求线程；立即失败又可能让短暂竞争变成大量业务重试。限时获取把这两个极端之间的边界写进代码，超时后可以返回“稍后重试”或交给异步队列处理。

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

final class OrderStateWriter {
    private final ReentrantLock lock = new ReentrantLock(true);

    boolean write(String orderId, String nextState) throws InterruptedException {
        if (!lock.tryLock(80, TimeUnit.MILLISECONDS)) {
            return false;
        }
        try {
            updateState(orderId, nextState);
            return true;
        } finally {
            lock.unlock();
        }
    }

    private void updateState(String orderId, String nextState) {
        // 只放需要互斥的内存状态更新；网络调用放在锁外
    }
}

这个例子有两个需要注意的细节。第一，tryLock(80, TimeUnit.MILLISECONDS) 的等待上限是业务约束，不是越大越好；第二，真正的共享状态更新才放进临界区，数据库或 HTTP 调用如果能移到锁外，就不要占着锁等待。

公平锁下 tryLock() 为什么仍可能插队

无参 tryLock() 是一次即时探测：只要调用瞬间锁空闲，它就可能直接拿到锁，即使已经有线程在公平队列里等待。代码审查时如果看到“公平锁 + 无参 tryLock”，不要把它理解成严格排队。

ReentrantLock fairLock = new ReentrantLock(true);

// 可能绕过已经等待的线程
boolean fastPath = fairLock.tryLock();
if (fastPath) {
    try {
        refreshCache();
    } finally {
        fairLock.unlock();
    }
}

// 需要遵守公平策略时，用可中断的定时版本
if (fairLock.tryLock(0, TimeUnit.MILLISECONDS)) {
    try {
        refreshCache();
    } finally {
        fairLock.unlock();
    }
}

零等待的定时版本仍然会检查中断，并按公平策略判断是否应该让出机会。是否采用它，取决于你要的是“探测锁是否空闲”，还是“遵守等待队列”。两者的业务语义不同。

中断、超时和 finally 要按同一条路径验收

带时间参数的获取方法会抛出 InterruptedException。未成功取得锁时，当前线程没有锁的所有权，不能在外层无条件调用 unlock()。成功取得后，释放动作要紧跟在 finally 的第一层保护里。

boolean acquired = false;
try {
    acquired = lock.tryLock(80, TimeUnit.MILLISECONDS);
    if (!acquired) {
        return false;
    }
    persistMemoryState();
    return true;
} catch (InterruptedException interrupted) {
    Thread.currentThread().interrupt();
    return false;
} finally {
    if (acquired) {
        lock.unlock();
    }
}

如果方法内部还会重入同一把锁，unlock() 只会减少持有计数，直到计数归零才真正让出锁。不要用“调用过几次 lock”这种隐含约定代替结构化的 try/finally。

上线前检查锁等待，而不是只测平均吞吐

测试时至少覆盖三类结果：竞争下成功、超时退出、线程被中断。把订单号、等待耗时、持有耗时和结果写入结构化日志，才能判断 80 毫秒是合理的业务边界，还是掩盖了临界区过长的问题。

• 公平参数：是否真的需要避免长期饥饿，吞吐下降是否可接受。
• 获取方式：快速探测、限时等待、无限等待分别对应什么业务结果。
• 释放边界：所有成功路径都进入 finally，未获取成功不释放。
• 中断处理：捕获后恢复中断标记，调用方能识别取消。
• 观测指标：锁等待 P95、超时率、持有时长和重试次数一起看。

常见问题

公平锁一定比非公平锁更安全吗？

不一定。公平锁解决的是竞争顺序和饥饿风险，不会自动修复死锁、临界区过长或错误的异常处理。

tryLock() 失败后应该立刻重试吗？

不要无间隔自旋。根据业务选择退避、入队或返回可重试结果，并设置合理的重试上限。

lock() 和 tryLock(timeout) 怎么选？

必须完成且能承受排队时使用 lock()；有明确响应上限或需要取消传播时，优先使用带超时版本。

锁内可以调用数据库吗？

能做不代表应该做。数据库、HTTP 和文件 IO 会放大锁持有时间，优先在锁外准备数据，锁内只提交必要的共享状态变化。

把公平性、等待上限和释放路径当成一个整体验收，ReentrantLock 才不会只是把 synchronized 换了个写法。真正上线前，先用等待分位数和超时业务结果校准临界区，再决定是否为公平性支付吞吐成本。