深入解析AQS独占模式与ReentrantLock源码实现

> ### 摘要 > 本文深入剖析Java并发包（JUC）中同步机制的核心基石——AbstractQueuedSynchronizer（AQS）独占模式，结合ReentrantLock的封装逻辑展开源码级解读。从AQS“状态管理+CLH队列+模板方法”三位一体的设计哲学出发，逐层解析acquire/release等关键流程；进而揭示ReentrantLock如何基于AQS实现可重入、公平/非公平策略及条件队列支持。文章不仅阐明“如何用”，更聚焦“为何如此实现”，助力开发者穿透API表象，掌握锁的底层运行机理。 > ### 关键词 > AQS,独占模式,ReentrantLock,源码解析,JUC ## 一、AQS基础原理 ### 1.1 AQS的基本概念与设计理念 在Java并发编程的浩瀚星图中，AbstractQueuedSynchronizer（AQS）宛如一座静默却坚不可摧的灯塔——它不直接暴露于应用层API的喧嚣之中，却以精妙的抽象，为整个JUC同步组件群落提供着底层脉搏。AQS并非一个可供直接实例化的工具类，而是一套高度凝练的**“状态管理+CLH队列+模板方法”三位一体的设计哲学**：它将同步状态的原子更新、线程阻塞与唤醒、等待队列的维护等共性逻辑尽数收束于自身，仅开放`tryAcquire`、`tryRelease`等寥寥几个钩子方法，交由子类按需定制语义。这种设计，既捍卫了复用性与一致性，又赋予了上层锁实现无与伦比的表达自由。它不言“锁”，却定义了锁何以为锁；它不谈“竞争”，却早已为每一次acquire与release埋下公平或非公平的伏笔。对开发者而言，理解AQS，不是为了背诵一行行volatile变量的读写顺序，而是真正触碰到并发控制那根最纤细也最坚韧的神经——那里没有魔法，只有设计者对状态、时序与协作近乎偏执的敬畏。 ### 1.2 AQS的核心数据结构与状态管理 AQS的心脏，是一颗被`volatile`守护的整型变量——`state`。它微小，却承载全部语义：在ReentrantLock中，它是重入次数；在Semaphore中，它是剩余许可数；在CountDownLatch中，它是倒计时阈值。这个看似朴素的字段，因`volatile`的内存可见性与`Unsafe`提供的CAS原子操作而成为线程安全的基石。围绕`state`旋转的，是那条由`Node`节点串联而成的**CLH（Craig, Landin, and Hagersten）变体队列**：每个等待线程被封装为一个`Node`，以FIFO顺序链接成双向链表——头节点代表当前持有同步状态的线程，其余节点则安静伫立于同步队列（Sync Queue）中，等待被唤醒。值得注意的是，AQS并未采用原始CLH的自旋等待，而是让节点进入`LockSupport.park()`的阻塞态，从而将CPU资源彻底让渡，只待`unpark()`一声令下。正是`state`的原子跃迁与CLH队列的有序调度，共同编织出独占模式下acquire/release流程的确定性骨架——它不承诺速度最快，但始终确保逻辑最稳、边界最清、意图最明。 ## 二、AQS独占模式解析 ### 2.1 独占模式的获取锁流程 当一个线程调用`acquire(int arg)`试图进入临界区，它并非莽撞闯入，而是在AQS的精密调度下，踏上一条由原子意志与队列纪律共同铺就的路径。这是一场关于“尝试—失败—入队—等待—唤醒”的四幕剧：线程首先以`tryAcquire(arg)`叩响同步状态的大门——此为子类实现的语义入口，在ReentrantLock中，它严谨校验当前线程是否已持有锁、是否可重入、以及公平性策略是否允许插队；若一击即中，`state`跃迁，线程昂然前行；若失之交臂，AQS便悄然启动第二幕：将该线程封装为`Node.EXCLUSIVE`节点，以CAS方式插入同步队列尾部——此处无争抢，唯有对`tail`指针的谦抑竞逐；第三幕随之静默展开：线程在入队成功后，进入自旋检测前置节点是否为头节点的短暂等待，一旦确认，便果断调用`LockSupport.park()`沉入阻塞态，将CPU让渡给世界；而真正的转机，藏于头节点释放锁后的`unparkSuccessor()`一瞬——它精准唤醒后继最急迫的那个等待者，使其重返`tryAcquire`的起点，开启新一轮确定性的循环。这不是随机的调度，而是以CLH队列为骨、以`state`为血、以模板方法为魂所构筑的独占秩序——每一次`acquire`，都是对“谁在等、为何等、何时醒”的无声重申。 ### 2.2 独占模式的释放锁机制 释放，从来不是简单地归还钥匙，而是一次对同步契约的郑重履约。当持有锁的线程调用`release(int arg)`，AQS即刻启动一场精微的“状态归零—队列唤醒—责任移交”三重奏：首步，交由子类实现的`tryRelease(arg)`执行语义层面的释放逻辑——在ReentrantLock中，它递减`state`值，并仅当`state`归零时才真正宣告锁的 relinquish；次步，若释放成功（即`tryRelease`返回`true`），AQS立即审视同步队列：若头节点非空且其后继节点有效，便触发`unparkSuccessor(Node node)`，唤醒紧邻头节点的第一个等待者；此处绝无模糊地带——唤醒目标被严格限定为`head.next`，且在多线程竞争下通过CAS确保唯一性；末步，被唤醒的线程苏醒后，并不直接获得锁，而是再次踏入`acquireQueued`的完整流程，重新竞争`state`所有权。这一机制冷峻而慈悲：冷峻在于它拒绝任何捷径，坚持“先入队、再唤醒、再竞争”的铁律；慈悲在于它确保每一次释放，都必然对应一次可预期的唤醒，绝不让等待者悬置在无人应答的虚空里。正是这种刚性与温度并存的设计，使独占模式在高并发洪流中，依然稳如磐石，脉络清晰。 ## 三、总结 本文围绕AQS独占模式与ReentrantLock的源码解析，系统揭示了JUC同步机制的底层实现逻辑。从AQS“状态管理+CLH队列+模板方法”的核心设计理念出发，深入剖析了`acquire`/`release`流程中状态原子更新、节点入队、线程阻塞与唤醒的完整闭环；进一步阐明ReentrantLock如何基于AQS扩展出可重入语义、公平性策略切换及条件队列支持。全文始终聚焦“为何如此实现”，而非止步于API用法，旨在帮助读者穿透表层封装，理解锁机制背后的状态语义、队列纪律与时序契约。掌握这些原理，是构建高可靠并发程序、进行深度性能调优与问题诊断的必要基础。