ReentrantLock.tryLock(long timeout, TimeUnit unit) 是带超时、可中断的非阻塞锁获取方式，会在指定时间内持续尝试获取锁，成功返回true，超时返回false，中断则抛出InterruptedException；它与无参tryLock的区别在于前者会挂起线程等待唤醒或超时，后者仅瞬时检查；使用时必须正确处理InterruptedException以保障中断语义。
ReentrantLock.tryLock(long timeout, TimeUnit unit) 是 Java 中一种带超时的、可中断的非阻塞式锁获取方式，它不会像 lock() 那样一直等待，也不会像无参 tryLock() 那样只做一次瞬时尝试，而是在指定时间内不断尝试获取锁，期间可响应线程中断。
超时机制的实际行为
该方法在以下任一情况发生时返回：
- 成功获取锁 → 返回
true； - 等待超时仍未获得锁 → 返回
false； - 等待过程中被其他线程中断 → 抛出
InterruptedException，不获取锁。
注意：超时时间从调用开始计算，包括因锁被占用而挂起的时间，也包括线程调度延迟等系统开销。它不是“最多尝试 N 次”，而是“最多等待 N 时间单位”。
与无参 tryLock 的关键区别
无参 tryLock() 是纯非阻塞的“快照式”尝试：立即检查锁状态，有空就拿，没空立刻返回 false，不挂起线程。而带超时版本会在锁不可用时让当前线程进入 WAITING 状态，并注册到 AQS 同步队列中，等待唤醒或超时。
立即学习“Java免费学习笔记（深入）”；
- 无参版适合对实时性要求极高、不能容忍任何等待的场景（如轮询任务）；
- 带超时版更适合需要“尽力而为 + 设定底线”的业务逻辑（如资源访问有 SLA 要求）。
使用时必须处理 InterruptedException
这是可中断锁的强制契约。如果忽略或仅打印堆栈却不恢复中断状态，会导致上层逻辑无法感知中断意图，破坏协作中断语义。
- 正确做法：捕获异常后通常应重新设置中断标志（
Thread.currentThread().interrupt()），或向上抛出； - 错误做法：空 catch 或只写
e.printStackTrace()； - 若业务允许取消操作，也可直接退出当前流程，无需重设中断。
典型应用场景示例
比如实现一个带保护时限的缓存加载：
if (lock.tryLock(100, TimeUnit.MILLISECONDS)) {
try {
// 检查缓存是否已更新（双重检查）
if (!cache.isValid()) {
cache.loadFromDB(); // 可能较慢
}
} finally {
lock.unlock();
}
} else {
// 超时未拿到锁，降级读旧缓存或返回错误
return cache.getStaleValue();
}
这种写法避免了所有线程在锁上长时间排队，提升了系统响应性和吞吐量。
