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
。