当前位置：首页 > 文章列表 > 文章 > java教程 > Java ReentrantLock tryLock 超时与资源释放

Java ReentrantLock tryLock 超时与资源释放

来源：17golang原创 2026-10-02 18:13:34 0浏览收藏

Java 中使用 ReentrantLock.tryLock(timeout, unit)，关键不是“等多久”，而是把三种结果分开处理：拿到锁后才进入临界区；等待时间耗尽返回 false；等待期间被中断则抛出 InterruptedException。只有成功拿锁的分支才能执行 unlock()，而文件、连接等业务资源也应在各自确定的生命周期内关闭。

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

要点速览

超时不是异常：false 表示本次没有进入临界区。
成功获取锁后立即进入 try/finally，把 unlock() 放在 finally 的第一层。
资源清理要区分“锁没拿到”和“资源已经创建”，不要用一个 finally 包住所有状态。

tryLock 的超时、成功和中断分别意味着什么

带超时的调用返回 true，说明当前线程已经成为锁的持有者；返回 false，说明在给定时间内没有获得锁，后续代码不应假设共享状态已经安全。若线程在等待期间被中断，方法抛出 InterruptedException，调用方应决定是向上抛出，还是恢复中断标记后结束本次任务。

结果	是否持锁	处理动作
`true`	是	进入临界区，最终 `unlock()`
`false`	否	记录超时、降级或重试，不调用 `unlock()`
抛出中断异常	通常否	恢复中断状态或继续抛出，结束本次等待

公平锁也要留意差异：无参 tryLock() 可以“插队”立即取得可用锁；带等待时间的形式在公平模式下会遵守队列倾向。需要公平语义但不想等待时，可以使用零超时的可中断形式，而不是把两种调用混成一个判断。

Java ReentrantLock tryLock 超时调用从等待输入分出成功、超时和中断结果的静态关系说明图 — 图1：ReentrantLock tryLock 的结果关系说明图，展示成功、超时与中断边界，不是运行截图。

先判断持锁结果，再创建临界区资源

常见错误是先创建连接或装载大对象，再等待锁；一旦超时，资源就可能在错误的层级泄漏。更稳妥的顺序是先等待锁，确认 true 后再准备只属于临界区的对象。如果资源必须在加锁前创建，则要单独记录“是否已创建”，并在未拿到锁的路径显式回收。

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

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

    boolean reserve(String sku) throws InterruptedException {
        // 超时只表示本次没有获得锁，不能把它当成业务成功。
        if (!lock.tryLock(200, TimeUnit.MILLISECONDS)) {
            return false;
        }
        try {
            // 只有持锁后才读取和修改共享库存状态。
            return updateInventory(sku);
        } finally {
            // finally 保证业务异常时也释放本线程持有的一层锁。
            lock.unlock();
        }
    }

    private boolean updateInventory(String sku) {
        // 示例只表达临界区边界，真实项目应在这里执行原子校验与更新。
        return sku != null && !sku.isBlank();
    }
}

这段写法的重点是 try 紧跟成功判断。不要把 lock.unlock() 放在 if 外层，也不要在 false 分支为了“对称”而解锁；那会触发 IllegalMonitorStateException，并掩盖真正的超时原因。

把锁释放和业务资源关闭拆成两个生命周期

锁保护的是共享状态，资源关闭保护的是文件描述符、连接或缓冲区，它们不一定同时创建、也不一定同时结束。若资源在成功拿锁后才创建，可以在临界区内部用资源自己的 try-with-resources，外层再用锁的 finally：

boolean writeOnce(Path path, byte[] data) throws InterruptedException {
    if (!lock.tryLock(300, TimeUnit.MILLISECONDS)) {
        // 没拿到锁时没有创建输出流，因此这里不做 close。
        return false;
    }
    try {
        // 资源由 try-with-resources 管理，写入失败也会自动关闭。
        try (OutputStream out = Files.newOutputStream(path)) {
            out.write(data);
            return true;
        }
    } finally {
        // 释放共享写入权，必须由当前成功持锁的线程执行。
        lock.unlock();
    }
}

如果业务要求“锁外准备、锁内提交”，则不要依赖对象是否为 null 来猜测清理状态，建议用布尔状态或明确的封装方法表达所有权。资源已经交给另一个组件后，当前层也不要重复关闭。