Java并发编程避坑指南：ReentrantLock的lock/unlock到底该怎么写才安全？
在Java并发编程的世界里，ReentrantLock就像一把双刃剑——用得好可以斩断线程安全的荆棘，用不好反而会伤及自身。很多开发者在初次接触这个灵活的锁机制时，常常陷入各种陷阱：锁未释放导致死锁、异常处理不当引发资源泄漏、Condition使用错误造成信号丢失...这些问题轻则导致性能下降，重则引发系统崩溃。本文将带你深入这些"坑点"，用真实的代码案例展示错误写法与正确姿势之间的微妙差别。
1. 锁的获取与释放：那些看似合理却暗藏杀机的写法
新手最常犯的错误莫过于认为lock()和unlock()简单配对使用就万事大吉。让我们看一个典型的错误案例：
ReentrantLock lock = new ReentrantLock(); public void riskyMethod() { lock.lock(); // 危险！如果这里抛出异常... try { // 业务代码 doSomething(); } finally { lock.unlock(); } }这段代码的问题在于：如果lock()调用本身抛出异常（比如中断异常），程序会直接跳出方法体，根本不会执行finally块中的unlock()。正确的做法应该是：
public void safeMethod() { try { lock.lock(); // 在try块内获取锁 doSomething(); } finally { lock.unlock(); } }关键区别：
- 错误写法中，
lock()在try块外，其异常会导致锁无法释放 - 正确写法将
lock()放在try块内，确保任何异常都能触发finally中的解锁
2. 异常处理：当业务逻辑遇上锁机制
异常处理是ReentrantLock使用中最容易被忽视的环节。考虑以下场景：
public void transfer(Account from, Account to, BigDecimal amount) { lock.lock(); try { from.debit(amount); // 可能抛出异常 to.credit(amount); // 可能抛出异常 } finally { lock.unlock(); } }这段代码存在两个潜在问题：
- 如果
debit()抛出异常，锁会被正常释放，但转账操作未完成 - 如果
credit()抛出异常，锁会被释放，但资金已从源账户扣除
更健壮的实现应该考虑事务性：
public void safeTransfer(Account from, Account to, BigDecimal amount) { lock.lock(); try { try { from.debit(amount); to.credit(amount); } catch (Exception e) { // 回滚逻辑 if (from.getBalance().compareTo(amount) < 0) { from.credit(amount); } throw e; } } finally { lock.unlock(); } }3. Condition的正确使用：避免信号丢失的陷阱
Condition是ReentrantLock的强大搭档，但也容易用错。看一个典型的生产者-消费者问题中的错误实现：
class Buffer { private final Lock lock = new ReentrantLock(); private final Condition notFull = lock.newCondition(); private final Condition notEmpty = lock.newCondition(); private final Queue<Integer> queue = new LinkedList<>(); private final int CAPACITY = 10; public void put(int value) { lock.lock(); try { while (queue.size() == CAPACITY) { notFull.await(); // 可能虚假唤醒 } queue.add(value); notEmpty.signal(); } finally { lock.unlock(); } } public int take() { lock.lock(); try { while (queue.isEmpty()) { notEmpty.await(); // 可能虚假唤醒 } int value = queue.poll(); notFull.signal(); return value; } finally { lock.unlock(); } } }这段代码看起来没问题，但实际上存在两个隐患：
- 虚假唤醒：
await()可能在没有signal()调用的情况下返回，所以必须用while而不是if检查条件 - 信号丢失：如果在
signal()之后才调用await()，信号会被丢失
更安全的做法是始终在修改共享状态后调用signal()：
public void safePut(int value) throws InterruptedException { lock.lock(); try { while (queue.size() == CAPACITY) { notFull.await(); } boolean wasEmpty = queue.isEmpty(); // 记录之前是否为空 queue.add(value); if (wasEmpty) { notEmpty.signal(); // 只在必要时发送信号 } } finally { lock.unlock(); } }4. 锁的可重入性与中断处理
ReentrantLock的可重入特性常常被误解。考虑这个递归场景：
public class RecursiveLockExample { private final ReentrantLock lock = new ReentrantLock(); public void outer() { lock.lock(); try { inner(); } finally { lock.unlock(); } } public void inner() { lock.lock(); // 可重入获取 try { // 递归逻辑 } finally { lock.unlock(); } } }这里inner()方法可以成功获取锁，因为outer()已经持有该锁。但要注意的是，每次lock()调用都必须有对应的unlock()，否则锁不会被释放。
另一个高级特性是中断响应。lockInterruptibly()方法允许在等待锁时响应中断：
public void interruptibleMethod() throws InterruptedException { try { lock.lockInterruptibly(); // 可被中断的获取方式 try { // 临界区代码 } finally { lock.unlock(); } } catch (InterruptedException e) { // 处理中断 Thread.currentThread().interrupt(); // 恢复中断状态 throw e; } }5. 性能优化：减少锁的持有时间
即使正确使用了ReentrantLock，性能问题也可能出现。关键在于最小化临界区：
// 不好的做法：锁持有时间过长 public void processData(List<Data> dataList) { lock.lock(); try { // 预处理（不需要同步） preprocess(dataList); // 需要同步的操作 synchronizedOperation(dataList); // 后处理（不需要同步） postprocess(dataList); } finally { lock.unlock(); } } // 优化后：只保护真正需要同步的部分 public void optimizedProcess(List<Data> dataList) { // 预处理（无锁） preprocess(dataList); // 仅同步必要部分 lock.lock(); try { synchronizedOperation(dataList); } finally { lock.unlock(); } // 后处理（无锁） postprocess(dataList); }性能对比：
| 方法 | 锁持有时间 | 吞吐量 | 可扩展性 |
|---|---|---|---|
| processData | 长 | 低 | 差 |
| optimizedProcess | 短 | 高 | 好 |
6. 调试与监控：定位锁相关问题
当并发问题出现时，ReentrantLock提供了一些调试工具：
ReentrantLock lock = new ReentrantLock(true); // 公平锁 // 获取锁信息 System.out.println("锁是否被持有: " + lock.isLocked()); System.out.println("持有锁的线程: " + lock.getOwner()); System.out.println("等待队列长度: " + lock.getQueueLength()); // 尝试获取锁（非阻塞） boolean acquired = lock.tryLock(); if (acquired) { try { // 临界区 } finally { lock.unlock(); } }对于更复杂的调试，可以使用ThreadMXBean：
ThreadMXBean threadMXBean = ManagementFactory.getThreadMXBean(); long[] threadIds = threadMXBean.findDeadlockedThreads(); if (threadIds != null) { ThreadInfo[] threadInfos = threadMXBean.getThreadInfo(threadIds); for (ThreadInfo threadInfo : threadInfos) { System.out.println("死锁线程: " + threadInfo.getThreadName()); System.out.println("等待锁: " + threadInfo.getLockName()); } }7. 最佳实践总结
经过以上分析，我们可以提炼出ReentrantLock的安全使用模板：
- 基本模式：
lock.lock(); try { // 临界区代码 } finally { lock.unlock(); }- 可中断模式：
try { lock.lockInterruptibly(); try { // 临界区代码 } finally { lock.unlock(); } } catch (InterruptedException e) { // 处理中断 Thread.currentThread().interrupt(); }- 超时模式：
if (lock.tryLock(1, TimeUnit.SECONDS)) { try { // 临界区代码 } finally { lock.unlock(); } } else { // 超时处理 }- Condition使用模式：
lock.lock(); try { while (!conditionMet) { condition.await(); } // 处理逻辑 condition.signalAll(); } finally { lock.unlock(); }记住这些原则，你的ReentrantLock代码将既安全又高效。在实际项目中，我习惯为每个锁添加注释说明其保护的对象和预期的并发场景，这在团队协作和后期维护中能节省大量时间。
