Java可重入锁ReentrantLock原理与实战指南

1. 可重入锁ReentrantLock基础解析

第一次接触ReentrantLock是在处理一个多线程订单系统时遇到的。当时系统频繁出现死锁，排查后发现是线程在递归调用中重复获取锁导致的。传统synchronized无法解决这个问题，直到发现了ReentrantLock这个神器。

1.1 什么是可重入锁

可重入锁（ReentrantLock）是Java并发包(java.util.concurrent.locks)中提供的一种显式锁实现。它的核心特性是允许同一个线程多次获取同一把锁，而不会产生死锁。这与synchronized关键字的行为类似，但提供了更灵活的锁控制机制。

举个例子，假设有个递归方法需要加锁：

public void recursiveMethod(int n) { lock.lock(); try { if (n <= 0) return; System.out.println("执行层级：" + n); recursiveMethod(n - 1); } finally { lock.unlock(); } }

使用普通非可重入锁时，第二次调用recursiveMethod就会因为无法获取已持有的锁而阻塞。而ReentrantLock允许这种情况发生，这就是"可重入"的含义。

1.2 核心特性与优势

与synchronized相比，ReentrantLock有几个显著优势：

1. 可中断的锁获取：通过lockInterruptibly()方法，可以在等待锁时响应中断
2. 尝试获取锁：tryLock()方法可以立即返回获取锁的结果，避免无限等待
3. 公平性选择：构造函数可以指定是否为公平锁（默认非公平）
4. 条件变量支持：可以创建多个Condition对象，实现精细化的线程通信

重要提示：使用ReentrantLock时必须手动释放锁，通常放在finally块中确保释放。忘记释放锁会导致严重问题。

2. ReentrantLock实现原理深度剖析

2.1 同步器AbstractQueuedSynchronizer(AQS)

ReentrantLock的核心实现依赖于AQS这个并发框架的基础组件。AQS内部维护了一个FIFO的等待队列和一个state状态变量。对于ReentrantLock：

• state=0：锁未被占用
• state>0：锁被占用，数值表示重入次数
• 等待队列存储被阻塞的线程

获取锁的基本流程：

1. 尝试通过CAS修改state从0到1
2. 成功则设置当前线程为独占线程
3. 失败则进入等待队列

2.2 公平锁与非公平锁实现差异

ReentrantLock在构造时可以指定公平性：

public ReentrantLock(boolean fair) { sync = fair ? new FairSync() : new NonfairSync(); }

非公平锁实现特点：

• 新请求的线程可以直接插队尝试获取锁
• 吞吐量更高，但可能导致某些线程饥饿
• 实现上直接尝试CAS获取锁，不检查队列

公平锁实现特点：

• 严格按照FIFO顺序获取锁
• 吞吐量较低，但保证公平性
• 实现上会先检查是否有等待线程

实测数据显示，在高并发场景下，非公平锁的性能可以比公平锁高出5-10倍。

2.3 重入计数实现

重入功能通过以下机制实现：

1. 记录当前持有锁的线程
2. 同一线程再次获取锁时，简单增加state计数
3. 释放锁时减少计数，只有计数归零时才真正释放

关键代码片段：

final boolean nonfairTryAcquire(int acquires) { final Thread current = Thread.currentThread(); int c = getState(); if (c == 0) { if (compareAndSetState(0, acquires)) { setExclusiveOwnerThread(current); return true; } } else if (current == getExclusiveOwnerThread()) { int nextc = c + acquires; if (nextc < 0) // overflow throw new Error("Maximum lock count exceeded"); setState(nextc); return true; } return false; }

3. 实战应用与性能优化

3.1 典型使用模式

标准的使用模板：

ReentrantLock lock = new ReentrantLock(); //... lock.lock(); try { // 临界区代码 } finally { lock.unlock(); }

高级用法示例- 带超时的锁获取：

if (lock.tryLock(1, TimeUnit.SECONDS)) { try { // 获取锁成功 } finally { lock.unlock(); } } else { // 超时处理 }

3.2 条件变量(Condition)的使用

Condition提供了类似Object.wait/notify的机制，但更灵活：

class BoundedBuffer { final Lock lock = new ReentrantLock(); final Condition notFull = lock.newCondition(); final Condition notEmpty = lock.newCondition(); void put(Object x) throws InterruptedException { lock.lock(); try { while (count == items.length) notFull.await(); items[putptr] = x; if (++putptr == items.length) putptr = 0; ++count; notEmpty.signal(); } finally { lock.unlock(); } } // 类似的take方法 }

3.3 性能优化技巧

1. 锁粒度控制：尽量减小临界区范围
2. 避免嵌套锁：容易导致死锁
3. 锁分段：对于高竞争场景，考虑使用ConcurrentHashMap的分段锁思想
4. 读写锁选择：读多写少场景考虑ReentrantReadWriteLock

实测数据对比（4核8G机器，100万次操作）：

4. 常见问题与排查指南

4.1 典型问题排查

问题1：锁未被释放症状：线程池中的线程逐渐耗尽 排查方法：

1. 使用jstack查看线程堆栈
2. 查找处于WAITING状态的线程
3. 检查是否所有lock()都有对应的unlock()

问题2：死锁症状：系统无响应，CPU利用率低 排查方法：

1. jstack查看死锁报告
2. 检查锁获取顺序是否一致
3. 使用tryLock设置超时

4.2 调试技巧

1. 使用ThreadMXBean检测死锁：

ThreadMXBean bean = ManagementFactory.getThreadMXBean(); long[] threadIds = bean.findDeadlockedThreads();

2. 给锁设置名称便于调试：

ReentrantLock lock = new ReentrantLock() { @Override public String toString() { return "OrderLock@" + hashCode(); } };

3. 使用可视化工具如JConsole、VisualVM监控锁竞争情况

4.3 最佳实践总结

1. 总是使用try-finally确保锁释放
2. 考虑使用tryLock避免无限等待
3. 高竞争场景优先选择非公平锁
4. 读写分离场景考虑读写锁
5. 避免在持有锁时调用外部方法（容易导致死锁）
6. 锁的获取和释放要在同一代码层级

在分布式系统中，ReentrantLock的本地特性使其不适用于跨JVM场景，此时需要考虑分布式锁方案如Redis或Zookeeper实现。