如何使用ReentrantLock显式加锁并配合try-finally释放-java教程-PHP中文网

ReentrantLock 必须在 try 块外调用 lock()，unlock() 必须在 finally 中执行，否则会导致锁泄漏；需严格匹配加锁/解锁次数，公平性设置不影响此规则。

如何使用reentrantlock显式加锁并配合try-finally释放

lock() 必须在 try 块外调用，且 unlock() 必须在 finally 中执行

这是最常出错的环节：把 lock() 放进 try 块里，或者漏掉 finally，都会导致锁泄漏。一旦某个线程因异常没走到 unlock()，后续所有线程就永远卡在 lock() 上。

lock() 调用本身可能不会抛异常，但它之后、try 之前若插入日志、参数校验等代码，而这些代码抛了异常，unlock() 就根本不会执行
unlock() 一定要写在 finally 里，哪怕临界区只有一行赋值也要套上 try-finally
不要在 catch 里调用 unlock() —— 异常可能发生在加锁前，此时调用会抛 IllegalMonitorStateException

正确写法：

lock.lock();
try {
    // 临界区逻辑
    sharedValue++;
} finally {
    lock.unlock();
}

为什么不能用 try-with-resources 或 catch 代替 finally

ReentrantLock 不实现 AutoCloseable，所以不能用于 try-with-resources；而 catch 只捕获特定异常，无法覆盖 RuntimeException、Error 等未声明异常，只有 finally 能 100% 保证执行。

即使 sharedValue++ 触发 NullPointerException 或 OutOfMemoryError，finally 仍会运行
若在 catch 里写 unlock()，而异常发生在 lock() 之前（比如构造参数校验失败），就会误释放未持有的锁
别信“我这逻辑很稳，不会出异常”——JVM 层面的 StackOverflowError 或 GC 暂停都可能打断流程

嵌套 lock() 时，unlock() 次数必须严格匹配

可重入不等于“自动配平”。每次 lock() 都会使内部计数器 +1，每次 unlock() -1；计数器归零才真正释放锁。少一次 unlock()，锁就一直被占着。

递归调用或 AOP 切面里不小心重复加锁，容易导致计数失衡
不要靠“感觉”数调用次数，用 IDE 的结构高亮或静态检查工具辅助识别嵌套层级
如果真需要多次加锁，建议用局部变量记录当前持有次数，或改用 tryLock() + 重试逻辑来规避深度嵌套

示例（合法但需谨慎）：

lock.lock();
try {
    lock.lock(); // 第二次加锁
    try {
        // ...
    } finally {
        lock.unlock(); // 对应第二次
    }
} finally {
    lock.unlock(); // 对应第一次
}