ReentrantLock必须在finally中unlock以防止锁泄漏；标准写法是lock()在try外、unlock()在finally内，并建议用isHeldByCurrentThread()校验持有状态。

ReentrantLock 本身不自动处理异常，它的异常保护机制完全依赖于开发者显式编码来保障——核心原则是：加锁后必须在 finally 块中释放锁。一旦漏掉 unlock()，就会导致锁泄漏，其他线程永久阻塞。

为什么异常会导致锁未释放？

如果 lock() 成功后、业务逻辑中抛出异常，且没有 try-finally 包裹，unlock() 就不会执行。例如：

错误写法（危险）：

lock.lock();
doSomething(); // 可能抛出 RuntimeException
lock.unlock(); // 异常时这行根本不会执行

结果是锁一直被占用，后续线程全部卡在 lock() 上，形成死锁假象。

标准防护写法：try-finally 是底线

无论是否捕获异常，只要加了锁，就必须用 finally 确保解锁：

• lock() 放在 try 块外或 try 块首行（避免 lock() 自身失败时进 finally 导致空指针）
• unlock() 必须放在 finally 块中
• 不需要在 catch 中重复 unlock()，finally 已覆盖所有退出路径

正确示例：

JavaScript 测试模式

使用 Jest、Vitest 和 Testing Library 实施全面的测试策略，包括单元测试、集成测试和端到端测试，涵盖模拟、测试夹具和测试驱动开发。在编

下载

lock.lock();
try {
    // 业务代码（可能抛异常）
    processOrder();
} finally {
    lock.unlock(); // 100% 执行
}

可中断获取：用 lockInterruptibly() 应对响应式场景

当线程在等待锁时被中断，lock() 会一直阻塞，而 lockInterruptibly() 能及时响应：

• 若调用时锁空闲，直接获取并继续执行
• 若锁被占，线程进入 WAITING 状态；此时收到 interrupt()，立即抛出 InterruptedException 并退出等待
• 该方法本身不持有锁，所以无需在 catch 中 unlock()

适用场景：需要主动取消长时间等待，比如服务优雅停机、超时熔断。

超时获取：tryLock(time, unit) 避免无限等待

相比无参 tryLock() 的“立即返回”，带超时的版本提供更可控的等待边界：

• 返回 true：成功获取锁，后续仍需 finally 解锁
• 返回 false：超时未获锁，可选择重试、降级或记录告警
• 抛 InterruptedException：说明等待中途被中断，同样不持有锁

它把“等待失败”变成可编程判断，而不是让线程陷在 park() 里无法感知外部状态。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南