深入解析Java中的ReentrantLock：设计思想、底层原理与源码剖析

Java中的ReentrantLock是java.util.concurrent.locks包中的一个核心类，广泛应用于高并发场景中。相比于传统的synchronized关键字，ReentrantLock提供了更灵活的锁操作控制。本文将从设计思想、底层原理、源码剖析、使用场景以及常见的误用情况等方面对ReentrantLock进行全面而深入的探讨。

1. 设计思想与动机

在Java中，synchronized关键字一直是并发编程中最常用的同步机制，它提供了简洁的语法和可靠的锁机制。然而，synchronized的使用也有一些局限性，比如无法中断的锁获取、不支持公平锁、无法尝试获取锁等。为了解决这些问题，Java在java.util.concurrent包中引入了Lock接口及其实现类ReentrantLock。

ReentrantLock的设计动机包括：

• 可中断的锁获取：允许在尝试获取锁时响应中断请求，避免死锁。
• 公平锁支持：提供了公平锁和非公平锁两种模式，用户可以根据需求选择。
• 可重入性：支持同一个线程多次获取锁，每次获取锁计数器加一，释放锁时计数器减一，直到计数器为零才真正释放锁。
• Condition支持：通过Condition接口，ReentrantLock支持更加灵活的线程协调机制，可以实现多个等待条件。

这些特性使得ReentrantLock成为一个强大而灵活的并发控制工具，适用于复杂的并发场景。

2. 底层原理与核心机制

ReentrantLock的实现基于AbstractQueuedSynchronizer（AQS），这是一个框架类，支持实现依赖队列的同步器。AQS提供了一种先进先出的（FIFO）等待队列，用于管理锁的获取和释放。ReentrantLock基于AQS的内部机制实现了其锁定逻辑。

2.1 锁的模式：公平与非公平

ReentrantLock提供了公平锁和非公平锁两种模式：

• 公平锁：按请求的绝对时间顺序获取锁，确保锁的公平性。即当一个线程请求锁时，如果有其他线程已经在等待队列中等待，则该线程必须排在队列末尾，等待前面的线程先获取锁。
• 非公平锁：线程可以抢占式地获取锁，即使有其他线程在等待队列中。非公平锁可以减少上下文切换，通常能提高吞吐量，但可能导致“线程饥饿”。

默认情况下，ReentrantLock采用非公平锁，除非在构造时明确指定使用公平锁。

2.2 可重入性

可重入性是ReentrantLock的重要特性之一。具体而言，如果一个线程已经持有了ReentrantLock的锁，那么它可以再次获取该锁，而不会被阻塞。每次成功获取锁，内部计数器state都会增加1，释放锁时state减少1，当state为0时，锁真正被释放。

2.3 Condition机制

ReentrantLock支持多个Condition对象，每个Condition对象都关联一个等待队列。与Object类的wait()和notify()方法不同，Condition允许更加灵活的等待/通知操作。比如，可以在一个锁上创建多个条件变量，以实现复杂的线程协调。

2.4 锁的获取与释放

ReentrantLock的核心方法包括lock()、unlock()、tryLock()等。lock()方法会尝试获取锁，如果锁被其他线程持有，则当前线程将进入等待状态，直到锁被释放。而unlock()方法则用于释放锁，如果state为0，则锁被真正释放，其他等待线程有机会获取锁。

3. 源码分析

要深入理解ReentrantLock，对其源码的分析是必不可少的。以下是对主要方法的解析：

3.1 构造函数

ReentrantLock有两个构造函数：

scss

代码解读

复制代码

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

sync是AbstractQueuedSynchronizer的子类，NonfairSync和FairSync分别实现了非公平锁和公平锁的逻辑。

3.2 lock()方法

以非公平锁为例，lock()方法实现如下：

这边整理了一份核心Java面试笔记包括了：Java面试、Spring、JVM、MyBatis、Redis、MySQL、并发编程、微服务、Linux、Springboot、SpringCloud、MQ、Kafka 面试专题

 需要全套面试笔记的【点击此处即可】免费获取

scala

代码解读

复制代码

public void lock() { sync.lock(); } static final class NonfairSync extends Sync { final void lock() { if (compareAndSetState(0, 1)) setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); } }

lock()首先尝试通过CAS操作设置state为1，如果成功，表示获取锁成功，并设置当前线程为持有者。如果CAS操作失败，表示锁已被其他线程持有，当前线程需要进入AQS的队列中等待。

3.3 unlock()方法

unlock()方法用于释放锁，具体实现如下：

ini

代码解读

复制代码

public void unlock() { sync.release(1); } protected final boolean tryRelease(int releases) { int c = getState() - releases; if (Thread.currentThread() != getExclusiveOwnerThread()) throw new IllegalMonitorStateException(); boolean free = false; if (c == 0) { free = true; setExclusiveOwnerThread(null); } setState(c); return free; }

unlock()通过tryRelease()方法尝试释放锁，减少state的值。如果state为0，表示锁被完全释放，AQS会唤醒等待队列中的下一个线程。

3.4 tryLock()方法

tryLock()方法用于非阻塞地尝试获取锁：

java

代码解读

复制代码

public boolean tryLock() { return sync.nonfairTryAcquire(1); } protected 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; }

tryLock()方法首先检查state是否为0，如果为0则通过CAS操作尝试获取锁；如果锁已被当前线程持有，则增加state的值，实现可重入性；如果锁已被其他线程持有，则返回false。

4. 使用场景与最佳实践

ReentrantLock在高并发环境中广泛应用，以下是一些典型的使用场景：

4.1 需要公平性保证的场景

在某些场景中，保证锁的公平性非常重要。例如，在银行系统中处理用户账户余额时，要求请求先到先处理，避免“饿死”现象。这时可以使用ReentrantLock的公平锁模式。

4.2 响应中断的场景

在一些需要响应中断的任务中，使用ReentrantLock可以通过lockInterruptibly()方法在锁等待过程中响应中断请求，避免线程永久阻塞。例如，在任务调度系统中，可能需要强制中断某些长时间占用资源的任务，此时ReentrantLock的中断特性尤为适用。

4.3 条件等待与通知的场景

ReentrantLock与Condition结合使用，适用于复杂的线程协调场景。例如，在生产者-消费者模型中，使用Condition可以将生产者和消费者放入不同的等待队列，生产者只通知消费者，消费者只等待生产者，避免了不必要的唤醒操作。

5. 常见误用与注意事项

尽管ReentrantLock功能强大，但不当的使用可能会导致一些问题。以下是一些常见的误用场景与注意事项：

5.1 忘记释放锁

使用ReentrantLock时，开发者必须显式地调用unlock()方法释放锁，而不像synchronized块那样自动释放。如果在执行完临界区代码后忘记释放锁，可能会导致其他线程无法获取锁，从而引发死锁或资源泄露。 在这种情况下，必须始终确保在finally块中释放锁：

csharp

代码解读

复制代码

// 正确示例 lock.lock(); try { // 临界区代码 } finally { lock.unlock(); }

5.2 误用tryLock()

tryLock()方法允许尝试获取锁而不会被阻塞，但如果错误地使用了tryLock()，可能会导致逻辑错误。例如，如果在循环中不断尝试获取锁，可能会导致忙等（busy-waiting），增加CPU的负担。

csharp

代码解读

复制代码

while (!lock.tryLock()) { // 忙等待，CPU负担过重 } try { // 临界区代码 } finally { lock.unlock(); }

此类使用方式不建议在高负载的场景中使用，应避免忙等待，考虑合适的重试间隔或其他控制机制。

5.3 不恰当地使用公平锁

公平锁会导致较高的上下文切换开销，适用于需要强公平性的场景。对于高吞吐量的场景，非公平锁通常表现更好。如果不正确使用公平锁，可能会导致性能瓶颈。

csharp

代码解读

复制代码

ReentrantLock lock = new ReentrantLock(true); // 公平锁

在性能敏感的场景中，建议根据需求进行评估，避免无意义地增加公平性开销。

5.4 在条件变量操作中使用不当

在使用Condition时，必须确保在获取锁后调用相应的Condition方法，���await()、signal()或signalAll()。如果在未持有锁的情况下调用这些方法，将抛出IllegalMonitorStateException。

csharp

代码解读

复制代码

Condition condition = lock.newCondition(); lock.lock(); try { condition.await(); // 错误，必须在持有锁的情况下调用 } finally { lock.unlock(); }

正确的做法是确保Condition方法的调用在锁保护下进行：

csharp

代码解读

复制代码

Condition condition = lock.newCondition(); lock.lock(); try { condition.await(); } finally { lock.unlock(); }

6. 总结

ReentrantLock是一个功能强大的并发工具，提供了比synchronized更多的灵活性和控制能力。其核心设计思想围绕可重入性、公平性和条件变量展开，使其在高并发场景中具有广泛的应用。通过深入理解ReentrantLock的底层原理、源码实现及其使用场景，可以更有效地利用这一工具提升系统的并发性能。

在实践中，正确使用ReentrantLock不仅能提高系统的吞吐量和响应能力，还能避免常见的误用问题，如锁的泄露、忙等待和不当的公平性设置。开发者应根据具体需求选择合适的锁策略，并通过仔细的代码审查和性能分析，确保在高并发环境中安全且高效地使用ReentrantLock。