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 管理线程调度——它同步的不是变量本身，而是对变量所代表资源的访问权。