CarrieYung1. ReentrantLock 的定位与核心特性
在并发编程领域，锁机制是控制多线程访问共享资源的基础工具。Java 中的 ReentrantLock 作为 synchronized 关键字的替代方案，提供了更灵活的锁操作方式。我第一次在生产环境使用 ReentrantLock 是在一个高并发的订单处理系统中，当时需要实现细粒度的锁控制，而 synchronized 无法满足我们的超时获取锁需求。
ReentrantLock 的核心特性体现在三个方面：可重入性、可中断性和公平性选择。可重入性意味着同一个线程可以多次获取同一把锁，这个特性在我调试递归算法时显得尤为重要。比如下面这段代码展示了一个典型的可重入场景：
java复制ReentrantLock lock = new ReentrantLock();
void recursiveMethod(int n) {
lock.lock();
try {
if (n <= 0) return;
System.out.println("Level " + n);
recursiveMethod(n - 1); // 递归调用仍能获取锁
} finally {
lock.unlock();
}
}
与 synchronized 相比，ReentrantLock 提供了更丰富的功能：
- 尝试非阻塞获取锁（tryLock）
- 可中断的获取锁（lockInterruptibly）
- 超时获取锁（tryLock with timeout）
- 公平锁与非公平锁的选择
- 获取锁的线程信息查询
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 底层实现架构解析
2.1 AQS 框架的核心地位
ReentrantLock 的实现重度依赖 AbstractQueuedSynchronizer（AQS）框架，这个设计模式让我想起第一次阅读源码时的震撼。AQS 采用模板方法模式，将锁的获取和释放操作抽象为对同步状态（state）的操作，而将线程排队、阻塞/唤醒等具体实现留给子类。
AQS 内部维护了一个 volatile int 类型的 state 变量和一个 FIFO 线程等待队列。在 ReentrantLock 的语境下，state 表示锁的重入次数：
- state = 0：锁未被占用
- state = 1：锁被某个线程独占
- state > 1：锁被同一个线程重入多次
2.2 同步队列的运作机制
当多个线程竞争锁时，AQS 的同步队列开始发挥作用。这个 CLH 变体队列的实现非常精妙，每个等待线程都被封装成一个 Node 节点。我曾在性能测试中发现，非公平锁模式下，新来的线程有可能"插队"成功，这解释了为什么在高竞争场景下非公平锁的吞吐量通常更高。
Node 节点中几个关键字段值得注意：
- waitStatus：表示线程状态（CANCELLED、SIGNAL等）
- thread：存放等待线程引用
- prev/next：维护队列结构
3. 锁的获取过程深度剖析
3.1 非公平锁的获取逻辑
非公平锁是 ReentrantLock 的默认模式，它的 lock() 方法实现如下：
java复制final void lock() {
if (compareAndSetState(0, 1)) // 先尝试快速获取
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1); // 进入AQS标准获取流程
}
这种"先抢后排队"的策略是我在电商秒杀系统中选择非公平锁的主要原因。在实际压力测试中，非公平锁比公平锁的吞吐量高出约30%，但代价是可能出现线程饥饿现象。
3.2 公平锁的严格顺序保证
公平锁的实现去掉了快速获取的尝试，直接进入队列排队：
java复制final void lock() {
acquire(1);
}
在 AQS 的 tryAcquire 方法中，公平锁会比非公平锁多一个检查：
java复制protected final boolean tryAcquire(int acquires) {
if (getState() == 0) {
if (!hasQueuedPredecessors() && // 关键区别：检查是否有前驱节点
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// ... 重入逻辑相同
}
4. 锁的释放与线程唤醒
4.1 unlock 的操作流程
解锁操作看似简单，但有几个容易踩坑的细节：
java复制public void unlock() {
sync.release(1);
}
在 release 方法中，会先将 state 减1，只有当 state 变为0时才真正释放锁。这意味着重入多次的锁需要解锁相同次数。我曾经在代码审查中发现过一个bug：开发者在递归方法中少调用了一次unlock，导致锁泄漏。
4.2 唤醒后继节点的策略
当锁释放时，AQS 会从队列头部开始寻找第一个需要唤醒的节点。这里有个实现细节：头节点的waitStatus如果小于0（通常是SIGNAL），才会触发后继节点的唤醒。这种设计避免了不必要的唤醒操作，提升了性能。
5. 高级特性实现原理
5.1 可中断的锁获取
lockInterruptibly() 的实现与普通获取的主要区别在于对中断信号的处理：
java复制public void lockInterruptibly() throws InterruptedException {
sync.acquireInterruptibly(1);
}
在 AQS 的 acquireInterruptibly 方法中，如果检测到线程中断标志，会立即抛出 InterruptedException。这个特性在我实现一个需要响应取消操作的任务队列时非常有用。
5.2 超时获取锁的实现
tryLock(long timeout, TimeUnit unit) 结合了超时控制和中断响应：
java复制public boolean tryLock(long timeout, TimeUnit unit)
throws InterruptedException {
return sync.tryAcquireNanos(1, unit.toNanos(timeout));
}
底层使用 LockSupport.parkNanos 实现精确的纳秒级等待。在分布式锁的本地缓存实现中，我常用这个特性来避免死锁。
6. 条件变量的工作机制
6.1 ConditionObject 的内部结构
ReentrantLock 的条件变量实现 ConditionObject 同样基于 AQS，它维护了一个单独的条件队列。当调用 await() 时，当前线程会加入这个队列；当调用 signal() 时，会将节点从条件队列转移到同步队列。
java复制Condition condition = lock.newCondition();
// 等待线程
lock.lock();
try {
while (!conditionSatisfied) {
condition.await(); // 释放锁并加入条件队列
}
} finally {
lock.unlock();
}
// 通知线程
lock.lock();
try {
conditionSatisfied = true;
condition.signal(); // 将节点转移到同步队列
} finally {
lock.unlock();
}
6.2 await/signal 的协作过程
await() 的完整流程包括：
- 创建节点加入条件队列
- 完全释放锁（考虑重入次数）
- 阻塞直到被signal或中断
- 重新获取锁
- 处理中断异常
这个机制在实现生产者-消费者模式时表现出色，比传统的 wait/notify 更灵活可控。
7. 性能优化与实战建议
7.1 锁选型决策树
根据我的经验，锁的选择可以遵循以下原则：
- 低竞争场景：synchronized（JVM会优化为偏向锁）
- 高竞争+需要高级功能：ReentrantLock
- 读多写少：ReadWriteLock
- 需要等待条件：Condition
7.2 常见陷阱与规避方案
-
锁泄漏：总是使用 try-finally 块确保 unlock 被调用
java复制lock.lock(); try { // 临界区代码 } finally { lock.unlock(); } -
死锁风险：使用 tryLock 设置超时，或实现死锁检测
-
性能问题：避免在锁保护的代码块中执行耗时操作
-
条件变量误用：signal() 只会唤醒一个线程，signalAll() 会唤醒所有等待线程
在实际项目中，我通常会封装一个 AutoCloseable 的锁包装器来简化资源管理：
java复制public class LockGuard implements AutoCloseable {
private final Lock lock;
public LockGuard(Lock lock) {
this.lock = lock;
lock.lock();
}
@Override
public void close() {
lock.unlock();
}
}
// 使用示例
try (LockGuard ignored = new LockGuard(lock)) {
// 临界区代码
}
8. 源码级调试技巧
理解 ReentrantLock 最好的方式是单步调试其源码。在 IDEA 中，我通常会：
-
设置断点在 AbstractQueuedSynchronizer 的关键方法：
- acquireQueued
- shouldParkAfterFailedAcquire
- unparkSuccessor
-
观察 state 和队列的变化：
java复制// 查看锁状态 System.out.println(lock.getHoldCount()); System.out.println(lock.isHeldByCurrentThread()); // 查看队列长度 System.out.println(lock.getQueueLength()); -
使用 jstack 分析运行时锁竞争情况
通过这种调试方式，我发现非公平锁在竞争激烈时确实会出现后申请锁的线程先获取到锁的情况，验证了其"插队"特性。