AQS自定义同步组件详解

AQS（AbstractQueuedSynchronizer）是Java并发包中构建锁与同步器的底层核心框架，它不直接同步变量，而是通过volatile state状态管理、CLH双向队列线程调度以及独占/共享两种模式的模板方法设计，为开发者提供定制化同步语义的能力——从ReentrantLock到CountDownLatch，再到自定义的BinaryLatch，本质都是将业务逻辑中的“资源访问条件”抽象为对state的原子操作，并由AQS统一处理排队、阻塞、唤醒等复杂线程协作细节；掌握其设计精髓，你就能跳出synchronized和volatile的局限，真正理解并实现高性能、可扩展的同步组件。

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

终于介绍完啦！小伙伴们，这篇关于《AQS自定义同步组件详解》的介绍应该让你收获多多了吧！欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识，快来关注吧！