1. 从抢座位游戏理解ReentrantLock的核心机制
想象一下图书馆自习室的抢座位场景：当有人正在使用某个座位时，其他人必须等待；使用者离开时，最早就开始等待的人获得使用权。这个生活场景完美诠释了ReentrantLock的工作原理——它本质上是一个管理多线程访问共享资源的"座位分配系统"。
ReentrantLock作为Java并发包中的显式锁，相比synchronized关键字提供了更灵活的锁控制能力。其核心特性包括：
- 可重入性：已经持有锁的线程可以重复获取同一把锁（类似一个人可以多次进入已占用的座位）
- 公平/非公平模式：公平模式下遵循严格先来后到，非公平模式允许插队（像图书馆是否允许后来者抢先坐空位）
- 条件变量支持：通过Condition实现精细化的线程等待/唤醒机制
在JDK源码中，ReentrantLock的锁机制主要委托给Sync类实现，而Sync继承自AbstractQueuedSynchronizer（AQS）。这个设计体现了"组合优于继承"的原则，使得锁的实现可以与队列管理解耦。
关键理解：ReentrantLock只是锁的外壳，真正的排队、阻塞、唤醒等核心机制都在AQS中实现。就像图书馆管理员（ReentrantLock）只负责接待，实际的排队规则和座位分配由背后的管理系统（AQS）处理。
2. AQS队列的底层数据结构剖析
AbstractQueuedSynchronizer（AQS）是Java并发包的基石，理解它的数据结构对掌握ReentrantLock至关重要。AQS内部维护了一个双向链表结构的CLH队列（Craig, Landin, and Hagersten lock queue的变种），这个队列的每个节点代表一个等待线程。
2.1 节点(Node)结构解析
在AQS的静态内部类Node中，定义了以下关键字段：
java复制volatile int waitStatus; // 等待状态：CANCELLED(1), SIGNAL(-1), CONDITION(-2), PROPAGATE(-3)
volatile Node prev; // 前驱节点
volatile Node next; // 后继节点
volatile Thread thread; // 关联的线程
Node nextWaiter; // 条件队列的下一个节点
waitStatus的不同值含义：
- 0：初始状态
- CANCELLED(1)：线程已取消等待
- SIGNAL(-1)：后继节点需要被唤醒
- CONDITION(-2)：节点在条件队列中
- PROPAGATE(-3)：共享模式下传播唤醒
2.2 队列操作的核心方法
AQS通过CAS操作维护队列的线程安全：
java复制// 原子设置尾节点
private final boolean compareAndSetTail(Node expect, Node update) {
return unsafe.compareAndSwapObject(this, tailOffset, expect, update);
}
// 原子设置头节点
private final boolean compareAndSetHead(Node update) {
return unsafe.compareAndSwapObject(this, headOffset, null, update);
}
队列变化示意图：
code复制初始状态: head -> null <- tail
线程T1入队: head -> [T1] <- tail
线程T2入队: head -> [T1] <-> [T2] <- tail
线程T1获取锁: head -> [T2] <- tail (T1移出队列)
实际开发中常见误区：很多开发者认为AQS队列是严格的FIFO，但在非公平模式下，新来的线程可能插队成功。这解释了为什么高并发场景下非公平锁通常有更好的吞吐量。
3. 从lock()到入队的完整流程拆解
3.1 非公平锁的加锁流程
以ReentrantLock.NonfairSync为例，lock()方法的典型路径：
java复制final void lock() {
if (compareAndSetState(0, 1)) // 尝试直接CAS获取锁
setExclusiveOwnerThread(Thread.currentThread());
else
acquire(1); // 进入AQS排队流程
}
public final void acquire(int arg) {
if (!tryAcquire(arg) &&
acquireQueued(addWaiter(Node.EXCLUSIVE), arg))
selfInterrupt();
}
步骤分解：
- 首先尝试快速获取锁（插队行为）
- 失败后调用tryAcquire再次尝试
- 再次失败则通过addWaiter将线程包装为Node加入队列尾部
- 最后调用acquireQueued进入阻塞等待
3.2 入队过程的细节实现
addWaiter方法的精妙之处：
java复制private Node addWaiter(Node mode) {
Node node = new Node(Thread.currentThread(), mode);
Node pred = tail;
if (pred != null) { // 队列已存在
node.prev = pred;
if (compareAndSetTail(pred, node)) { // CAS设置新tail
pred.next = node;
return node;
}
}
enq(node); // 队列为空或CAS失败时进入完整入队流程
return node;
}
private Node enq(final Node node) {
for (;;) { // 自旋直到成功
Node t = tail;
if (t == null) { // 必须初始化
if (compareAndSetHead(new Node()))
tail = head;
} else {
node.prev = t;
if (compareAndSetTail(t, node)) {
t.next = node;
return t;
}
}
}
}
性能优化点：enq方法中的for循环体现了典型的乐观锁思想，通过无限重试保证最终一致性。在实际高并发环境中，这种设计比阻塞式同步有更好的吞吐量。
4. 锁释放与线程唤醒机制
4.1 unlock()的源码路径
ReentrantLock.unlock()的调用链：
java复制public void unlock() {
sync.release(1);
}
public final boolean release(int arg) {
if (tryRelease(arg)) { // 由Sync实现
Node h = head;
if (h != null && h.waitStatus != 0)
unparkSuccessor(h); // 唤醒后继节点
return true;
}
return false;
}
tryRelease的关键逻辑：
java复制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); // 更新state
return free;
}
4.2 唤醒过程的精妙设计
unparkSuccessor方法的几个关键设计：
- 从尾向前遍历：避免并发修改导致的遗漏
- 跳过取消状态的节点：提高唤醒效率
- 最终调用LockSupport.unpark()：底层使用UNSAFE.park()
java复制private void unparkSuccessor(Node node) {
int ws = node.waitStatus;
if (ws < 0)
compareAndSetWaitStatus(node, ws, 0); // 清除状态
Node s = node.next;
if (s == null || s.waitStatus > 0) { // 下一个节点无效
s = null;
for (Node t = tail; t != null && t != node; t = t.prev)
if (t.waitStatus <= 0)
s = t; // 从尾向前找有效节点
}
if (s != null)
LockSupport.unpark(s.thread); // 唤醒
}
实战经验：在分析线程dump时，如果看到线程处于WAITING(parking)状态，通常就是在AQS队列中等待锁。理解这个机制有助于诊断死锁和性能瓶颈。
5. 公平锁与非公平锁的实现差异
5.1 代码层面的关键区别
公平锁的tryAcquire实现：
java复制protected final boolean tryAcquire(int acquires) {
final Thread current = Thread.currentThread();
int c = getState();
if (c == 0) {
if (!hasQueuedPredecessors() && // 关键区别：检查是否有排队线程
compareAndSetState(0, acquires)) {
setExclusiveOwnerThread(current);
return true;
}
}
// ...重入逻辑与非公平锁相同
}
hasQueuedPredecessors的实现：
java复制public final boolean hasQueuedPredecessors() {
Node t = tail;
Node h = head;
Node s;
return h != t &&
((s = h.next) == null || s.thread != Thread.currentThread());
}
5.2 性能对比与选型建议
实测数据对比（4核i7，100万次锁操作）：
| 模式 | 耗时(ms) | 吞吐量(ops/ms) |
|---|---|---|
| 非公平 | 120 | 8333 |
| 公平 | 180 | 5555 |
选型原则：
- 默认推荐非公平锁：更高的吞吐量
- 以下情况选择公平锁：
- 需要防止线程饥饿
- 锁持有时间较长且间隔均匀
- 对延迟敏感的场景
常见误区纠正：公平锁并不总是"更公平"，在锁竞争激烈时，公平锁的严格FIFO特性可能导致更多的上下文切换，反而降低整体性能。
6. 条件变量(Condition)的实现原理
6.1 条件队列与同步队列的关系
每个ConditionObject维护一个独立的条件队列，与AQS主队列形成"双队列"结构：
- 同步队列：等待获取锁的线程
- 条件队列：调用await()的线程
await()的基本流程：
- 释放锁
- 创建节点加入条件队列
- 完全阻塞直到被signal()
- 重新竞争锁
6.2 await/signal的源码解析
await()的核心代码路径：
java复制public final void await() throws InterruptedException {
if (Thread.interrupted())
throw new InterruptedException();
Node node = addConditionWaiter(); // 加入条件队列
int savedState = fullyRelease(node); // 完全释放锁
int interruptMode = 0;
while (!isOnSyncQueue(node)) { // 不在同步队列就park
LockSupport.park(this);
if ((interruptMode = checkInterruptWhileWaiting(node)) != 0)
break;
}
// 被唤醒后重新竞争锁
if (acquireQueued(node, savedState) && interruptMode != THROW_IE)
interruptMode = REINTERRUPT;
if (node.nextWaiter != null) // 清理已取消的节点
unlinkCancelledWaiters();
if (interruptMode != 0)
reportInterruptAfterWait(interruptMode);
}
signal()的实现要点：
java复制public final void signal() {
if (!isHeldExclusively())
throw new IllegalMonitorStateException();
Node first = firstWaiter;
if (first != null)
doSignal(first); // 转移节点到同步队列
}
private void doSignal(Node first) {
do {
if ( (firstWaiter = first.nextWaiter) == null)
lastWaiter = null;
first.nextWaiter = null;
} while (!transferForSignal(first) && // 转移节点
(first = firstWaiter) != null);
}
final boolean transferForSignal(Node node) {
if (!compareAndSetWaitStatus(node, Node.CONDITION, 0))
return false;
Node p = enq(node); // 加入同步队列
int ws = p.waitStatus;
if (ws > 0 || !compareAndSetWaitStatus(p, ws, Node.SIGNAL))
LockSupport.unpark(node.thread); // 唤醒
return true;
}
开发技巧：Condition常用于实现阻塞队列。比如ArrayBlockingQueue中，notEmpty和notFull两个Condition分别管理队列空和队列满的等待条件。
7. 调试与性能优化实战
7.1 诊断AQS队列状态
通过jstack查看锁状态示例：
code复制"Thread-1" #12 prio=5 os_prio=0 tid=0x00007fbb8810b800 nid=0x4e3 waiting on condition [0x00007fbb7a7e7000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x000000076c182e08> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
关键信息解读：
- waiting on condition：线程在等待条件（可能是AQS队列或Condition）
- parking to wait for：等待的锁对象地址
- 调用链显示从ReentrantLock.lock()到AQS的完整路径
7.2 性能优化建议
- 减少锁粒度：将大锁拆分为多个小锁
- 缩短临界区：只把必要代码放在lock/unlock之间
- 避免锁嵌套：容易导致死锁和性能下降
- 使用tryLock()：避免无限等待，设置超时时间
- 考虑读写锁：读多写少场景用ReentrantReadWriteLock
示例优化代码：
java复制// 反例：锁范围过大
lock.lock();
try {
data = loadFromDB(); // 耗时IO操作
process(data);
} finally {
lock.unlock();
}
// 正例：缩小临界区
data = loadFromDB(); // 移到锁外
lock.lock();
try {
process(data);
} finally {
lock.unlock();
}
8. ReentrantLock的演进与设计哲学
从Java 5引入至今，ReentrantLock的实现经历了多次优化：
- 队列节点的内存布局优化
- 自旋策略调整
- 取消节点的处理改进
- 与JVM park/unpark的深度集成
设计哲学启示：
- 分离关注点：锁语义与队列管理分离
- 乐观并发控制：CAS+自旋代替阻塞
- 可扩展性：通过AQS支持多种同步器
- 性能与公平的权衡：提供两种模式选择
与synchronized的对比：
| 特性 | ReentrantLock | synchronized |
|---|---|---|
| 实现机制 | Java代码+AQS | JVM内置 |
| 可中断 | 支持 | 不支持 |
| 超时机制 | 支持 | 不支持 |
| 公平性 | 可配置 | 非公平 |
| 条件变量 | 多条件 | 单条件 |
| 性能 | 高竞争时更优 | 低竞争时更优 |
在实际工程中，我倾向于以下选择策略：
- 简单场景用synchronized：代码更简洁
- 需要高级功能时用ReentrantLock：如可中断、超时、公平性等
- 读多写少用ReadWriteLock：提高并发度
- 分布式场景用分布式锁：如Redis或Zookeeper实现