当前位置：首页 > 文章列表 > 文章 > java教程 > Java ReentrantLock 公平锁怎么选：tryLock、超时与解锁边界

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

来源：17golang原创 2026-08-20 19:51:39 0浏览收藏

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

要点速览

公平锁主要控制竞争时的获取顺序，不能保证线程调度绝对公平。
无参 tryLock() 会立即抢占空闲锁；需要尊重公平队列时使用带时间参数的版本。
成功获取后必须由同一线程在 finally 中释放，超时或中断未获取成功时不能调用 unlock()。
生产验收要同时看等待耗时、超时比例和锁持有时间，不能只看吞吐量。

先把 ReentrantLock 的三个选择分开

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

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

调用方式	等待行为	适合场景
`lock()`	一直等到成功或线程被终止	业务必须完成、可接受排队
`tryLock()`	立即返回，空闲就拿到	快速探测，允许放弃本次处理
`tryLock(timeout, unit)`	限时等待，可响应中断	有 SLA 的状态更新或批处理

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

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

Java ReentrantLock 公平队列中订单回写请求从等待到获取锁的证据面板

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 中 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。