深入解析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用法，旨在帮助读者穿透表层封装，理解锁机制背后的状态语义、队列纪律与时序契约。掌握这些原理，是构建高可靠并发程序、进行深度性能调优与问题诊断的必要基础。