AQS是Java并发基石，因其将线程排队、状态判断、阻塞唤醒封装为可复用骨架，使开发者只需定义资源获取与释放逻辑；其核心是volatile int state变量、FIFO同步队列、acquire/release统一入口及Condition条件等待机制。
Java并发需要AQS，根本原因在于：它把“线程排队、状态判断、阻塞唤醒”这些重复又易错的底层逻辑，封装成可复用的骨架，让开发者只需专注定义“什么算拿到资源”和“什么算释放资源”——而不是自己手写死锁风险高、CAS循环难控、队列管理混乱的同步代码。
state 状态变量是同步决策的唯一依据
AQS只用一个 volatile int state 就承载所有同步语义。这个值本身没有固定含义，完全由子类解释：
- ReentrantLock 中，
state == 0表示锁空闲，state > 0表示被持有，数值即重入次数 - CountDownLatch 中，
state是倒计时剩余值，减到 0 才放行等待线程 - Semaphore 中，
state是当前可用许可数，acquire 减一，release 加一
所有判断都基于 CAS 原子操作修改 state，避免竞态，也无需 synchronized 加锁——这是高效的基础。
FIFO 同步队列自动管理等待线程
当线程 tryAcquire 失败，AQS 不会忙等或随意 park，而是：
立即学习“Java免费学习笔记（深入）”；
- 把当前线程封装成 Node，用 CAS 安全插入双向链表尾部（tail）
- 设置前驱节点的 waitStatus = SIGNAL，表示“我挂起后，请你唤醒我”
- 调用 LockSupport.park() 阻塞自己，真正交出 CPU
队列按进入顺序服务，天然公平；头节点（head）始终指向已获取资源的线程，释放时只唤醒 head.next，逻辑清晰不发散。
acquire/release 是统一入口，模式解耦清晰
AQS 不强制你做独占还是共享，而是提供两套正交模板：
- 独占式：acquire / release → 用于 ReentrantLock、WriteLock
- 共享式：acquireShared / releaseShared → 用于 Semaphore、CountDownLatch、ReadLock
子类只需实现对应的 tryXXX 方法，AQS 自动处理排队、阻塞、唤醒、中断响应（如 acquireInterruptibly）、超时（tryAcquireNanos）等细节。不用重复造轮子，也不用担心 signal 丢失或虚假唤醒。
Condition 支持灵活的条件等待
除了主同步队列，AQS 还内置 ConditionObject，支持类似 wait/notify 的条件等待：
- 每个 Condition 对应一个单向条件队列，await 时把线程从同步队列移到条件队列
- signal 时把节点移回同步队列尾部，参与后续竞争
- Lock 可拥有多个独立 Condition，比如 ReentrantLock.newCondition() 可创建“数据就绪”“缓冲区空”等不同语义的等待集
这比 Object monitor 的单一 wait set 更精细，也更安全（不会因 notifyAll 误唤醒无关线程）。
基本上就这些。AQS 不是万能锁，但它把并发中最容易出错的“排队+状态+唤醒”三件套标准化了。你写的不是锁，而是对业务资源的一句声明：“我要这个，没得就等；我不要了，通知下一个”。
