AQS是Java并发包中构建锁和同步器的底层框架，通过volatile int state管理同步状态、CLH双向队列处理线程排队与唤醒，并提供独占/共享模式及模板方法（如tryAcquire），使开发者能定制同步语义而非直接同步变量。
AbstractQueuedSynchronizer（AQS）不是用来“自定义变量同步组件”的工具，而是 Java 并发包中构建锁和同步器的底层框架。它本身不直接同步变量，而是提供统一的队列管理、线程阻塞/唤醒、状态原子更新等核心能力，让开发者能基于它实现自己的同步语义（比如独占锁、共享锁、信号量、CountDownLatch 等）。
理解 AQS 的核心职责
AQS 本质是一个用于构建同步器的模板类，关键设计包括：
-
state 字段：一个 volatile int，由子类通过
getState()/setState()/compareAndSetState()安全操作，代表同步状态（如锁的持有次数、剩余许可数、计数值等）； - CLH 同步队列：维护等待获取同步状态的线程节点（Node），实现公平/非公平排队；
- 独占与共享两种模式：子类决定如何解释 state 和响应 acquire/release 操作；
-
模板方法设计：子类必须重写
tryAcquire、tryRelease、tryAcquireShared、tryReleaseShared等钩子方法，定义具体同步逻辑。
为什么不能直接用 AQS “同步变量”？
AQS 不提供对任意字段的自动加锁或可见性保障。例如，你不能把一个 int count 交给 AQS 去“保护”。它只负责管理“谁有资格执行某段逻辑”，而非“让某个变量线程安全”。要保证变量线程安全，仍需：
- 使用
volatile（适用于简单状态标志）； - 加锁（如
synchronized或ReentrantLock）包裹读写； - 用原子类（如
AtomicInteger）； - 若该变量的状态变更与同步器语义强相关（如“资源是否可用”），才适合映射到 AQS 的
state上，并在tryAcquire中判断。
典型自定义同步器示例：BinaryLatch（二元门闩）
模拟类似 CountDownLatch(1) 的功能，但更轻量：
- state = 0 表示已打开（可通行），state = 1 表示关闭（需等待）；
-
tryAcquireShared返回 -1（失败）或 1（成功），控制线程是否阻塞； -
releaseShared将 state 从 1 设为 0，并唤醒所有等待线程； - 所有线程安全都由 AQS 的 state CAS + 队列机制保障，无需额外 synchronized。
正确使用 AQS 的关键提醒
避免常见误区：
- 不要在 AQS 子类中暴露或直接修改
state—— 必须通过模板方法封装语义； - 钩子方法必须是无锁、快速返回的；耗时操作（如 IO、复杂计算）应移出；
- 务必调用
acquire/release等公共方法，而非绕过 AQS 直接操作队列； - 调试时可借助
getQueueLength()、hasQueuedThreads()观察等待线程状态。
真正需要的是根据业务同步需求，把“条件判断”和“状态转换”抽象成对 state 的操作，并交由 AQS 管理线程调度——它同步的不是变量本身，而是对变量所代表资源的访问权。
