Java 循环屏障 CyclicBarrier 怎么配合 AQS 实现-java教程-PHP中文网

cyclicbarrier未直接使用aqs，而是基于reentrantlock+condition自主实现；其核心用volatile int count管理状态，通过lock保证临界区、condition.await()挂起线程、signalall唤醒全部线程，并自行处理中断、超时与重置。

java 循环屏障 cyclicbarrier 怎么配合 aqs 实现

CyclicBarrier 本身不直接使用 AQS（AbstractQueuedSynchronizer）作为底层实现，而是基于 ReentrantLock + Condition 自主构建等待队列和唤醒机制。 它和 AQS 没有继承或组合关系，但设计思想与 AQS 高度相似——比如状态管理、线程阻塞/唤醒、公平性控制等。理解它如何“绕开 AQS 却做着类似的事”，才是关键。

核心状态用 int 类型原子维护

CyclicBarrier 内部用一个 private int count 记录还需到达的线程数，初始值为 parties（参与方总数）。每次 await() 调用成功，count 就减 1。当 count 减到 0，说明所有线程已就位，触发屏障动作（如执行 barrierAction），然后重置 count 为 parties，进入下一轮循环。

这个 count 的更新不是靠 AQS 的 state 字段，而是靠 ReentrantLock 配合 CAS 式的 tryLock + compareAndSet 模拟：实际是用 lock.lock() 保证临界区，再用普通 volatile int 更新，配合 condition.await() 实现等待。

等待队列靠 Condition 实现，而非 AQS 的 CLH 队列

CyclicBarrier 内部持有一个 ReentrantLock lock 和一个 Condition trip（名字取自“trip the barrier”）。线程调用 await() 时：

先加锁，检查是否已打破（broken）、是否已完成（count == 0）、是否超时等
若需等待，调用 trip.await() —— 这会把当前线程挂起，并加入 Condition 关联的等待队列（由 AQS 的 ConditionObject 维护）
当最后一个线程到达并调用 trip.signalAll()，所有在该 Condition 上等待的线程被唤醒，重新竞争 lock，继续执行后续逻辑

注意：这里的 Condition 是 AQS 提供的，但 CyclicBarrier 并未直接复用 AQS 的独占/共享同步逻辑；它只是借用了 Condition 的等待/通知能力，同步控制仍由自己封装。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

中断、超时、重置等行为全部自行处理

AQS 提供了标准的中断响应（acquireInterruptibly）、超时获取（tryAcquireNanos）模板，但 CyclicBarrier 没走这些路径。它自己实现：

await() 中检测 Thread.interrupted()，抛出 InterruptedException
带超时的 await(long, TimeUnit) 用的是 lock.tryLock(timeout)，失败则主动清理并返回 false
reset() 方法手动将 count 重置、标记 broken、signalAll 唤醒所有等待者 —— 这些都是显式调用 lock 和 condition 的结果

也就是说，CyclicBarrier 把“同步协调”的职责全揽下来，AQS 只是它工具箱里的一把螺丝刀（用于 Condition），而不是整台发动机。