“AQS 的核心就是 一个 volatile int state + 一个 CLH（Craig, Landin, Hagersten 人物名称） 变种双向队列。

state 负责记录资源状态，所有状态变更都通过 CAS 保证原子性；

当线程获取资源失败时，会把自己包装成 Node 加入 FIFO（First In First Out 先进先出） 队列，然后 park 阻塞，避免自旋浪费 CPU。

释放资源时会 unpark 队列中第一个有效等待线程。

正因为有了这个队列，AQS 既能大幅降低 CPU 开销，又能天然支持公平锁。

ReentrantLock 就是典型例子：state 表示重入次数，公平/非公平的区别就在于获取锁前是否检查队列。”

与之类似的还有 Redisson 的分布式锁（通过 redis 监听唤醒等待中的线程）Redisson分布式锁流程

AQS 基础认知：定位与核心问题

AQS 是什么？

抽象队列同步器（AbstractQueuedSynchronizer），是 Java 并发包（java.util.concurrent）中最底层的同步框架，几乎所有锁和同步工具（如 ReentrantLock、Semaphore、CountDownLatch、ReentrantReadWriteLock、ThreadPoolExecutor 等）都是基于 AQS 实现的。

AQS 解决什么问题？

主要解决多线程竞争共享资源时的高效同步控制，核心攻克以下三大痛点：

• 资源状态的准确管理
• 线程调度的公平性问题
• 自旋等待导致的 CPU 资源严重浪费

如果没有 AQS，我们自己该怎么设计锁？

必须手动实现三大机制：

1. 资源状态标识：用 volatile int + CAS（如 AtomicInteger.compareAndSet）
2. 线程等待/唤醒机制：用 LockSupport.park()/unpark() 替代无限自旋
3. 公平性保障：自己维护一个 FIFO 等待队列（CLH 变种队列）

AQS 核心组件：两大支柱

同步状态（state）

• 本质：一个 volatile int state 变量，表示资源的当前状态
• 经典示例：
  • ReentrantLock：state = 0 → 锁空闲；state > 0 → 已被占用（数值表示重入次数）
  • Semaphore：state 表示剩余可用许可数
  • CountDownLatch：state 表示还需要等待的次数