一、核心设计思想
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
单一等待集的局限性。
适用场景
- 需要可中断、超时或公平锁的高并发场景。
- 复杂线程协作场景(如生产者-消费者模型、线程池任务调度)。
除非注明,否则均为李锋镝的博客原创文章,转载必须以链接形式标明本文链接
文章评论