ReentrantLock深度解析
一、核心设计思想 1. 可重入性（Reentrancy） 定义：同一线程可多次获取同一把锁，通过计数器记录持有次数，释放时需完全解锁（计数器归零）
一、核心设计思想
1. 可重入性（Reentrancy）
定义：同一线程可多次获取同一把锁，通过计数器记录持有次数，释放时需完全解锁（计数器归零）。
示例代码：
ReentrantLock lock = new ReentrantLock();
lock.lock();
try {
lock.lock(); // 可重入，计数器+1
// 临界区代码
} finally {
lock.unlock(); // 计数器-1
lock.unlock(); // 计数器归零，释放锁
}
2. 公平性（Fairness）
公平锁：按请求顺序（FIFO）分配锁，避免线程饥饿，适合高竞争场景。
非公平锁（默认）：允许线程插队，减少上下文切换开销，适合低竞争场景，吞吐量更高。
3. 显式锁控制
手动加锁/解锁：需通过try-finally确保锁释放，避免死锁。
灵活性：支持tryLock（尝试获取）、lockInterruptibly（可中断获取）、超时获取等。
二、底层实现：AQS（AbstractQueuedSynchronizer）
ReentrantLock基于AQS框架实现，通过CLH双向队列管理等待线程，核心依赖state状态变量和节点（Node）机制。
1. AQS核心机制
state变量：表示锁的持有计数（0为未锁定，≥1为锁定次数）。
CLH队列：保存等待线程的双向链表，每个节点封装线程状态（如CANCELLED、SIGNAL）。
2. 加锁流程（非公平锁为例）
3. 解锁流程
public void unlock() {
sync.release(1); // 调用AQS的release方法
}
// AQS的release方法
public final boolean release(int arg) {
if (tryRelease(arg)) { // 尝试释放锁（ReentrantLock实现）
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h); // 唤醒队列中下一个线程
return true;
}
return false;
}
三、公平锁 vs 非公平锁的源码差异
1. 非公平锁（NonfairSync）
final boolean nonfairTryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (compareAndSetState(0, acquires)) { // 直接CAS，允许插队
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) { // 可重入
setState(c + acquires);
return true;
}
return false;
}
2. 公平锁（FairSync）
protected final boolean tryAcquire(int acquires) {
Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() && // 检查队列是否有等待线程
compareAndSetState(0, acquires)) { // 无等待时才CAS
setExclusiveOwnerThread(current);
return true;
}
} else if (current == getExclusiveOwnerThread()) { // 可重入
setState(c + acquires);
return true;
}
return false;
}
四、高级功能与使用场景
1. 可中断锁获取（lockInterruptibly）
ReentrantLock lock = new ReentrantLock();
try {
lock.lockInterruptibly(); // 响应中断
// 临界区代码
} catch (InterruptedException e) {
// 处理中断逻辑
} finally {
lock.unlock();
}
2. 超时尝试获取锁（tryLock）
if (lock.tryLock(1, TimeUnit.SECONDS)) { // 等待1秒
try {
// 临界区代码
} finally {
lock.unlock();
}
} else {
// 超时处理
}
3. 条件变量（Condition）
对比synchronized的wait/notify：支持多个条件变量，实现精细化线程协作。
示例：生产者-消费者模型
ReentrantLock lock = new ReentrantLock();
Condition notFull = lock.newCondition(); // 队列未满条件
Condition notEmpty = lock.newCondition(); // 队列非空条件
// 生产者
lock.lock();
try {
while (queue.isFull()) {
notFull.await(); // 等待队列未满
}
queue.add(item);
notEmpty.signal(); // 唤醒消费者
} finally {
lock.unlock();
}
// 消费者
lock.lock();
try {
while (queue.isEmpty()) {
notEmpty.await(); // 等待队列非空
}
item = queue.remove();
notFull.signal(); // 唤醒生产者
} finally {
lock.unlock();
}
五、最佳实践与常见问题
1. 必须手动释放锁
错误示例（可能导致死锁）：
lock.lock();
// 若此处抛出异常，锁无法释放！
lock.unlock();
正确做法：
lock.lock();
try {
// 临界区代码
} finally {
lock.unlock(); // 确保锁释放
}
2. 避免嵌套锁导致死锁
风险代码：
lockA.lock();
try {
lockB.lock(); // 若另一线程先获取lockB，会死锁
} finally {
lockB.unlock();
lockA.unlock();
}
解决方案：按固定顺序获取锁（如先锁A后锁B）。
3. 性能调优建议
优先使用非公平锁：默认策略，适合大多数场景。
减少锁粒度：采用分段锁（如ConcurrentHashMap的分段设计）。
监控锁竞争：使用jstack或JFR分析线程阻塞情况。
六、ReentrantLock vs synchronized
特性
ReentrantLock
synchronized
实现方式
JDK类，基于AQS
JVM内置关键字
锁获取方式
显式调用lock()/unlock()
隐式获取（代码块/方法）
公平性
支持公平/非公平锁
仅非公平锁
可中断性
支持（lockInterruptibly）
不支持
超时机制
支持（tryLock）
不支持
条件变量
支持多个Condition
单一wait/notify
性能
高竞争下更优（可配置策略）
Java 6后优化，低竞争下接近
代码复杂度
高（需手动管理锁）
低（自动释放）
七、源码分析：AQS的等待队列
// AQS中的Node类（简化版）
static final class Node {
volatile int waitStatus; // 等待状态（CANCELLED=1, SIGNAL=-1等）
volatile Node prev; // 前驱节点
volatile Node next; // 后继节点
volatile Thread thread; // 关联的线程
Node nextWaiter; // 条件队列中的下一个节点
}
// CLH 队列示意图
Head -> Node(Thread1, SIGNAL) ↔ Node(Thread2, CANCELLED) ↔ Tail
八、总结
设计亮点
基于AQS的模板模式：将锁逻辑委托给子类（公平锁/非公平锁）实现。
分离公平性策略：通过不同Sync子类支持灵活的锁分配机制。
条件变量精细化控制：解决synchronized单一等待集的局限性。
适用场景
需要可中断、超时或公平锁的高并发场景。
复杂线程协作场景（如生产者-消费者模型、线程池任务调度）。
除非注明，否则均为李锋镝的博客原创文章，转载必须以链接形式标明本文链接本文链接：https://www.lifengdi.com/article/tech/4436
相关文章JAVA之从线程安全说到锁CompletableFuture使用详解别再背线程池的七大参数了，现在面试官都这么问UUID太长怎么办？快来试试NanoIdJAVA关键字之volatile关键字说明
