Java ReentrantLock tryLock 超时与资源释放

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

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

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

公平锁也要留意差异：无参 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 来猜测清理状态，建议用布尔状态或明确的封装方法表达所有权。资源已经交给另一个组件后，当前层也不要重复关闭。

用检查清单验证超时与释放边界

压测或单元测试不必只看“最终库存是否正确”，还要观察每条路径的边界行为：

• 让一个线程持锁超过等待时间，确认竞争线程得到 false，且没有调用解锁。
• 在等待线程上调用 interrupt()，确认异常被正确传递或中断状态被恢复。
• 在临界区主动抛出异常，确认 finally 仍执行；下一次竞争应能继续获得锁。
• 检查 getHoldCount() 与业务日志，确认重入次数和解锁次数匹配。

不要把超时设置得极短来“提高吞吐”，也不要把它当成锁泄漏的修复手段。超时只是等待策略；真正的资源释放仍取决于所有权、异常路径和关闭顺序。

常见问题

tryLock 返回 false 后需要调用 unlock 吗？

不需要。返回 false 代表当前线程没有获得这把锁，调用 unlock 反而会抛出非法监视器状态异常。

InterruptedException 被捕获后应该怎么做？

如果当前层无法处理取消语义，通常恢复中断标记并结束任务；如果能处理，则记录原因后按业务约定退出，不能静默吞掉中断。

资源一定要在锁内创建吗？

不一定。只要明确资源所有权和失败回收路径即可；为了避免超时造成浪费，临界区专属资源通常更适合在成功拿锁后创建。