CyclicBarrier的核心用途是让一组线程互相等待直至全部到达屏障点后才共同继续执行；它支持重复使用，所有线程地位对等，调用await()后阻塞，最后一线程到达时触发屏障动作并唤醒全部线程。
什么是 CyclicBarrier 的核心用途
CyclicBarrier 本质是让一组线程互相等待，直到全部到达某个“屏障点”才一起继续执行。它和 CountDownLatch 不同：后者是一次性、由主线程等待子线程；而 CyclicBarrier 支持重复使用，且所有参与线程地位对等——每个线程调用 await() 后都会被阻塞，直到最后一个线程到达。
如何正确初始化并触发屏障
构造时必须指定参与线程数，可选传入一个 Runnable 作为“屏障动作”（在最后一线程到达时、释放所有线程前执行）：
int parties = 3;
CyclicBarrier barrier = new CyclicBarrier(parties, () -> {
System.out.println("所有线程已就位，执行汇总逻辑");
});
- 如果只传
parties，屏障动作为空，线程到达后直接唤醒 -
parties值必须 ≥1；传 0 会抛IllegalArgumentException - 屏障动作运行在线程池中最后一个调用
await()的那个线程上，不是新线程 - 若屏障动作抛出异常（如
RuntimeException），该异常会包装为BrokenBarrierException并传播给所有正在await()的线程
await() 调用的常见陷阱
await() 是阻塞方法，可能抛出三种异常，每种对应不同场景：
-
InterruptedException：当前线程在等待时被中断 → 需要恢复中断状态或显式处理 -
BrokenBarrierException：屏障已被破坏（比如某线程超时退出、被中断，或屏障动作抛异常）→ 此时isBroken()返回true，需调用reset()才能重用 -
TimeoutException：用了带超时的await(long timeout, TimeUnit unit)且未在时限内凑齐全部线程
错误写法示例（忽略异常导致程序静默失败）：
立即学习“Java免费学习笔记（深入）”；
try {
barrier.await(); // ❌ 没 catch 任何异常
} catch (Exception e) {
// ❌ 吞掉异常，后续逻辑可能错乱
}
推荐写法（至少区分处理）：
try {
barrier.await(10, TimeUnit.SECONDS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 恢复中断状态
} catch (TimeoutException e) {
System.err.println("等待超时，屏障未达成");
barrier.reset(); // 主动重置，避免后续 await 立即失败
} catch (BrokenBarrierException e) {
System.err.println("屏障已损坏：" + e.getMessage());
barrier.reset();
}
reset() 和 isBroken() 的实际意义
reset() 会将屏障重置为初始状态，但要注意：它不会唤醒已阻塞的线程，那些线程仍会收到 BrokenBarrierException。真正安全的重用方式是：确保所有线程都已离开 await()，再调用 reset()。
-
isBroken()返回true表示屏障处于损坏状态，此时所有后续await()都会立即抛BrokenBarrierException - 调用
reset()后，isBroken()变回false，但已有等待线程不受影响 - 多线程并发调用
reset()和await()是线程安全的，但逻辑上应避免竞态（例如一个线程刚reset()，另一个还在await()中）
真正容易被忽略的是：屏障动作里不能依赖其他线程已完成计算——因为它执行时，其余线程还卡在 await() 返回之前。所有共享数据必须在屏障动作中完成同步读取或更新。
