CyclicBarrier 可重复使用，因其通过 ReentrantLock 保障计数与状态切换原子性、Condition 实现“等齐再放行”的精准唤醒、Generation 机制隔离轮次状态，三者协同支持多轮同步。
CyclicBarrier 的底层不是靠 AQS 直接实现，而是封装了 ReentrantLock 和 Condition 来完成线程协作——它用锁保护计数操作，用条件队列管理等待与唤醒，整个过程干净、可控、可重入。
为什么选 ReentrantLock 而不是 synchronized
ReentrantLock 提供了更精细的并发控制能力，CyclicBarrier 需要保证 count 递减的原子性 和 状态切换的安全性。比如多个线程同时调用 await()，必须确保只有一个线程能成功修改 count，其余线程要么阻塞、要么触发 barrierAction。synchronized 缺乏超时、中断响应、多条件队列等能力，而 ReentrantLock 支持：
- 显式加锁/解锁，配合 try-finally 避免死锁风险
- 可响应中断（lockInterruptibly）——CyclicBarrier.await() 可被 interrupt 中断
- 支持公平/非公平策略（虽 CyclicBarrier 默认用非公平，但底层具备扩展性）
Condition 是怎么配合完成“等齐再放行”的
CyclicBarrier 内部只定义了一个 Condition 实例（叫 trip），所有等待线程都注册在这个条件队列上：
- 线程调用 await() 后，先加锁 → 减 count → 判断是否为最后一个（count == 0）
- 如果不是最后一个，就执行 trip.await() 进入等待状态，释放锁并挂起
- 如果是最后一个，执行 barrierAction（如有）→ 调用 trip.signalAll() 唤醒全部等待线程
- 被唤醒的线程重新竞争锁，检查当前 generation 是否有效（防中断污染），然后返回
Generation 机制让“重用”真正安全
每次所有线程通过屏障后，CyclicBarrier 不是简单把 count 重置为 parties，而是：
立即学习“Java免费学习笔记（深入）”；
- 新建一个 Generation 对象，标记新轮次
- 将 broken 状态归零，隔离上一轮的中断或异常影响
- count 重置为 parties，trip 条件队列自动清空（因 signalAll 已唤醒全部）
这样即使某轮被中断（broken = true），下一轮仍能正常启动，不会误判失败状态。
和 CountDownLatch 的关键区别就在这里
CountDownLatch 是单次倒计时器，基于 AQS 的 state 字段做递减，归零即不可逆；CyclicBarrier 是“有状态的循环门”，它的重用性来自三者协同：
- ReentrantLock —— 保障 count 修改和 generation 切换的原子性
- Condition —— 实现精准的“集体阻塞 + 集体唤醒”语义
- Generation —— 提供轮次隔离，使 reset 行为天然安全
