ReentrantLock的定义和特性

总结

ReentrantLock是Java中的可重入互斥锁，提供线程同步功能。支持公平/非公平模式，允许线程重复获取锁且不会死锁。特性包括可中断锁获取、超时尝试锁及Condition条件变量。需手动加锁解锁，相比synchronized更灵活控制并发，适用于复杂多线程场景。

详细解析

ReentrantLock是 Java 并发包（java.util.concurrent.locks）中提供的一种显式可重入互斥锁，用于在多线程环境中控制对共享资源的访问。它通过手动获取和释放锁的方式，提供了比synchronized关键字更灵活、更细粒度的锁控制能力。

一、核心特性

1. 可重入性（Reentrant）

与synchronized类似，ReentrantLock支持可重入性：同一个线程可以多次获取同一把锁而不会被阻塞（通过记录锁的“持有次数”实现）。例如，线程 A 获取锁后，在未释放的情况下可以再次获取该锁，锁的计数器会递增，直到所有获取操作都被对应释放（计数器归零），其他线程才能获取该锁。

2. 显式锁管理

与synchronized隐式（自动获取/释放锁）不同，ReentrantLock是显式锁：

• 通过lock()方法主动获取锁；
• 通过unlock()方法主动释放锁（必须在finally块中调用，避免因异常导致锁未释放而死锁）。

示例：

1 2 3 4 5 6 7

ReentrantLock lock = new ReentrantLock(); try {     lock.lock(); // 显式获取锁     // 临界区代码（操作共享资源） } finally {     lock.unlock(); // 显式释放锁（必须在finally中） }

3. 公平锁与非公平锁（Fair vs Non-fair）

ReentrantLock支持两种锁策略，通过构造函数参数控制：

• 非公平锁（默认）：线程获取锁的顺序与等待队列无关，新线程可能“插队”直接获取锁（提高吞吐量，但可能导致部分线程长时间等待）。
• 公平锁：严格按照等待队列的顺序分配锁（先等待的线程先获取锁，避免“线程饥饿”，但性能略低）。

构造方式：

1 2	ReentrantLock fairLock = new ReentrantLock(true); // 公平锁 ReentrantLock nonFairLock = new ReentrantLock(); // 非公平锁（默认）

4. 可中断的锁获取

ReentrantLock提供lockInterruptibly()方法，允许在等待锁的过程中响应中断（通过Thread.interrupt()）。这避免了synchronized中线程一旦进入阻塞状态就无法被中断的问题。

示例：

1 2 3 4 5 6 7 8 9 10 11

try {     lock.lockInterruptibly(); // 可中断的锁获取     // 临界区代码 } catch (InterruptedException e) {     // 线程被中断时的处理逻辑     Thread.currentThread().interrupt(); // 恢复中断状态 } finally {     if (lock.isHeldByCurrentThread()) { // 检查当前线程是否持有锁（避免异常释放）         lock.unlock();     } }

5. 超时获取锁

通过tryLock(long timeout, TimeUnit unit)方法，线程可以尝试在指定时间内获取锁。若超时未获取到锁，则返回false，避免无限等待。

示例：

1 2 3 4 5 6 7 8 9

if (lock.tryLock(1, TimeUnit.SECONDS)) { // 尝试1秒内获取锁     try {         // 临界区代码     } finally {         lock.unlock();     } } else {     // 超时处理逻辑（如放弃操作） }

6. 条件变量（Condition）支持

ReentrantLock可以通过newCondition()方法创建多个Condition对象（条件变量），实现更细粒度的线程等待/通知机制。相比synchronized仅能通过wait()/notify()共享一个等待队列，Condition支持多个独立的等待队列，适合复杂的线程协调场景（如生产者-消费者模型中的不同条件）。

示例（生产者-消费者）：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

ReentrantLock lock = new ReentrantLock(); Condition notFull = lock.newCondition();  // 队列未满条件 Condition notEmpty = lock.newCondition(); // 队列未空条件 // 生产者放入元素 lock.lock(); try {     while (queue.size() == MAX_SIZE) {         notFull.await(); // 等待队列非满     }     queue.add(element);     notEmpty.signal(); // 通知消费者队列非空 } finally {     lock.unlock(); } // 消费者取出元素 lock.lock(); try {     while (queue.isEmpty()) {         notEmpty.await(); // 等待队列非空     }     queue.poll();     notFull.signal(); // 通知生产者队列非满 } finally {     lock.unlock(); }

二、与synchronized的对比

特性	synchronized	ReentrantLock
锁类型	隐式锁（自动获取/释放）	显式锁（手动获取/释放）
可重入性	支持	支持
公平性	非公平（默认）	支持公平/非公平（可配置）
可中断性	不支持（阻塞后无法中断）	支持（lockInterruptibly()）
超时获取锁	不支持	支持（tryLock(timeout)）
条件变量	仅1个（wait()/notify()）	支持多个独立Condition对象
锁状态查询	不支持（无法感知锁是否被持有）	支持（如isLocked()、getQueueLength()）
代码复杂度	简单（语法糖）	较高（需手动管理锁）

三、适用场景

ReentrantLock适合需要更灵活锁控制的场景，例如：

• 需要公平锁策略（避免线程饥饿）；
• 需要可中断或超时获取锁（防止死锁）；
• 需要多个条件变量（如复杂的生产者-消费者模型）；
• 需要监控锁的状态（如调试或性能优化）。

四、注意事项

• 必须手动释放锁：unlock()需在finally块中调用，确保锁必然释放，避免死锁。
• 公平锁的性能：公平锁虽然更“公平”，但需维护严格的等待队列，通常性能低于非公平锁（默认策略）。
• 条件变量的正确使用：Condition.await()必须在锁的保护下调用（即先获取锁），否则会抛出IllegalMonitorStateException。

五、总结

ReentrantLock是synchronized的增强版，通过显式锁管理提供了更灵活的并发控制能力（如可中断、超时、公平锁、多条件变量）。在需要高级锁特性时（如复杂线程协调），ReentrantLock是更优选择；而简单同步场景（如基础互斥）则推荐使用synchronized（代码更简洁）。