面试官总问AQS？看完这篇就够了：手把手图解ReentrantLock加锁解锁全流程（附高清时序图）

深度解析ReentrantLock的AQS实现从加锁到解锁的全链路剖析在Java并发编程领域理解AbstractQueuedSynchronizerAQS的工作原理是掌握JUC包的核心钥匙。作为ReentrantLock、Semaphore等同步器的基石AQS通过精巧的设计实现了线程排队、阻塞与唤醒机制。本文将采用全链路拆解可视化分析的方式带你深入ReentrantLock的非公平锁实现特别适合准备中高级Java面试的开发者系统性地掌握这一关键技术。1. AQS架构全景透视1.1 核心设计思想AQS的本质是一个同步状态管理器其核心是一个volatile int类型的state变量和内置的CLH队列变体。这个双端队列将竞争资源的线程封装为Node节点通过CAS操作实现线程安全的状态变更// AQS核心字段 private transient volatile Node head; // 队首指针 private transient volatile Node tail; // 队尾指针 private volatile int state; // 同步状态关键设计特点状态抽象state变量表示资源状态如ReentrantLock中0未锁定1锁定1重入次数队列管理采用虚拟头节点的双向队列CLH变体避免并发操作时的竞态条件模板模式通过tryAcquire/tryRelease等protected方法支持不同同步器的定制1.2 Node节点数据结构每个等待线程被封装为Node对象其关键字段构成如下字段名类型作用waitStatusint节点状态CANCELLED1, SIGNAL-1, CONDITION-2prevNode前驱节点指针nextNode后继节点指针threadThread绑定的线程对象nextWaiterNode条件队列专用链接注意队列的第一个节点始终是虚拟节点Dummy Node它的thread字段为null仅作为占位符存在。真正的等待线程从第二个节点开始排列。2. 非公平锁加锁全流程2.1 lock()方法入口以非公平锁为例加锁流程始于ReentrantLock.NonfairSync.lock()final void lock() { if (compareAndSetState(0, 1)) // 快速尝试获取锁 setExclusiveOwnerThread(Thread.currentThread()); else acquire(1); // 进入AQS标准获取流程 }非公平性体现在新来的线程无需排队直接通过CAS抢锁。这与公平锁的hasQueuedPredecessors()检查形成对比。2.2 acquire()方法的三步曲当快速获取失败时进入AQS的核心方法acquire(int arg)public final void acquire(int arg) { if (!tryAcquire(arg) acquireQueued(addWaiter(Node.EXCLUSIVE), arg)) selfInterrupt(); }这个复合条件构成了经典的三步流程tryAcquire子类实现的获取逻辑addWaiter将线程包装为Node并入队acquireQueued在队列中等待获取资源2.2.1 tryAcquire实现ReentrantLock中的非公平尝试获取protected final boolean tryAcquire(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) throw new Error(Maximum lock count exceeded); setState(nextc); return true; } return false; }2.2.2 addWaiter入队操作当tryAcquire失败时线程需要加入等待队列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更新尾节点 pred.next node; return node; } } enq(node); // 队列未初始化或CAS失败 return node; }关键点使用尾插法保证线程安全初始空队列时通过enq方法初始化虚拟头节点节点模式Node.EXCLUSIVE表示独占模式2.2.3 acquireQueued队列中等待入队后的线程进入阻塞等待状态final boolean acquireQueued(final Node node, int arg) { boolean interrupted false; try { for (;;) { // 自旋 final Node p node.predecessor(); if (p head tryAcquire(arg)) { // 前驱是头节点且获取成功 setHead(node); // 当前节点成为新头 p.next null; // 帮助GC return interrupted; } if (shouldParkAfterFailedAcquire(p, node) parkAndCheckInterrupt()) // 阻塞线程 interrupted true; } } catch (Throwable t) { cancelAcquire(node); throw t; } }等待策略检查前驱节点是否为头节点即自己是否处于队列最前端通过shouldParkAfterFailedAcquire将前驱节点的waitStatus设为SIGNAL(-1)调用LockSupport.park()进入阻塞状态3. 解锁与线程唤醒机制3.1 unlock()触发释放解锁操作始于ReentrantLock.unlock()public void unlock() { sync.release(1); // 进入AQS释放流程 }3.2 release()的核心步骤AQS的标准释放流程public final boolean release(int arg) { if (tryRelease(arg)) { // 子类实现释放 Node h head; if (h ! null h.waitStatus ! 0) unparkSuccessor(h); // 唤醒后继节点 return true; } return false; }3.2.1 tryRelease实现ReentrantLock中的释放逻辑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; }3.2.2 unparkSuccessor唤醒机制唤醒后继节点的关键操作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); // 唤醒线程 }唤醒策略从尾向前遍历确保找到真正的有效节点调用LockSupport.unpark()唤醒线程被唤醒的线程会在acquireQueued中继续尝试获取锁4. 高频面试要点精析4.1 为什么需要虚拟头节点虚拟节点又称哨兵节点的设计解决了多个并发问题队列初始化原子性空队列时头尾指针都指向虚拟节点避免CAS竞争简化边界条件所有真实节点都有前驱统一了入队逻辑状态标识通过虚拟节点的waitStatus传递信号4.2 非公平锁的性能优势与公平锁相比非公平锁减少了线程切换的开销减少挂起/唤醒次数新线程有机会直接获取锁避免不必要的上下文切换利用时间局部性刚释放锁时缓存热度高CAS成功率更高吞吐量优先虽然可能导致线程饥饿但在高竞争场景下整体性能更优4.3 中断处理机制AQS对中断的响应分为两个层次acquire不响应中断仅记录中断状态通过selfInterrupt恢复acquireInterruptibly立即抛出InterruptedException// 典型的中断处理模式 if (shouldParkAfterFailedAcquire(p, node) parkAndCheckInterrupt()) // 阻塞时被中断 interrupted true;4.4 状态变更的原子性保障AQS通过组合使用以下技术保证线程安全volatile变量state、head、tail等关键字段的可见性CAS操作compareAndSetState/compareAndSetTail等原子更新锁降级在复杂操作中先读volatile再检查5. 实战中的注意事项5.1 避免锁泄漏确保在finally块中释放锁ReentrantLock lock new ReentrantLock(); lock.lock(); try { // 临界区代码 } finally { lock.unlock(); // 绝对执行 }5.2 合理设置等待时间对于可能死锁的场景使用tryLock带超时版本if (lock.tryLock(3, TimeUnit.SECONDS)) { try { // 临界区 } finally { lock.unlock(); } } else { // 超时处理 }5.3 监控锁竞争情况通过AQS提供的工具方法诊断系统状态// 获取等待队列长度 int queueLength lock.getQueueLength(); // 检查是否有线程在等待 boolean hasQueuedThreads lock.hasQueuedThreads();在实际性能调优中这些数据可以帮助识别瓶颈所在。我曾在一个高并发订单系统中发现某个锁的平均等待线程数达到15时系统吞吐量会急剧下降这促使我们重构了锁的粒度。