该用CyclicBarrier而非CountDownLatch时：需多线程彼此等待、同时出发，且需重复使用；CyclicBarrier支持循环重用，适用于分段执行+同步汇合+迭代场景。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
当多个线程需要「彼此等待、同时出发」时，CyclicBarrier 是更自然的选择。比如并行计算中，每个线程处理数据块后必须等全部完成，再一起进入下一轮聚合；而 CountDownLatch 更适合「一个线程等其他线程全部结束」这种单向等待。
关键区别在于重用性：CyclicBarrier 可被重复 await() 多次（名字里的 “Cyclic” 就是这个意思），CountDownLatch 一旦计数归零就不可重置。
- 适合场景：多线程分段执行 + 同步汇合 + 循环迭代（如模拟多轮游戏、分批处理+汇总）
- 不适合场景：仅需一次等待（用
CountDownLatch更轻量）、线程间无协作依赖（可能根本不需要屏障） - 注意：
CyclicBarrier的构造参数是参与线程总数，不是剩余待等待数 —— 容易和CountDownLatch(int)的语义混淆
CyclicBarrier 的 Runnable 回调在哪个线程执行
当最后一个线程调用 await() 并触发屏障释放时，你传入的 Runnable（即 barrier action）由「那个最后到达的线程」同步执行 —— 不是新线程，也不是主线程，更不是固定线程池中的某一个。
这意味着：
立即学习“Java免费学习笔记（深入）”；
- 回调逻辑不能耗时或阻塞，否则会拖慢所有等待线程的唤醒速度
- 如果回调里抛出异常（如
RuntimeException），该异常会包装为BrokenBarrierException并传播给所有正在await()的线程 - 若不需要全局协调动作，可传
null，避免无谓开销
如何安全地处理 CyclicBarrier.await() 的异常
await() 方法声明抛出两种受检异常：InterruptedException 和 BrokenBarrierException。后者表示屏障被破坏（比如某个线程超时退出、中断，或回调抛异常），此时整个屏障失效，后续调用都会立即抛出该异常。
典型处理方式：
- 必须捕获
InterruptedException并考虑是否恢复中断状态（Thread.currentThread().interrupt()） - 遇到
BrokenBarrierException通常意味着协作已失败，应中止当前任务或重置屏障（调用reset()，但要注意：这会唤醒所有等待线程并让它们收到BrokenBarrierException） - 若设置了超时（
await(long, TimeUnit)），还要处理TimeoutException，它同样会导致屏障进入破损状态
try {
barrier.await(10, TimeUnit.SECONDS);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return; // 或抛出自定义异常
} catch (TimeoutException e) {
System.err.println("Barrier timeout, aborting");
barrier.reset(); // 可选：尝试恢复，但需确保其他线程也配合
} catch (BrokenBarrierException e) {
System.err.println("Barrier broken, check upstream failure");
return;
}
和 Phaser 比，为什么有时还得选 CyclicBarrier
Phaser 功能更强大（支持动态注册/注销线程、分阶段、树形结构），但复杂度和开销也更高。如果你只需要固定数量线程的简单「到齐即发」，CyclicBarrier 更直观、内存占用更小、JVM 对其优化更成熟。
真实权衡点：
- 线程数固定且已知？→
CyclicBarrier足够 - 需要中途加入/退出参与者？→ 必须用
Phaser - 要对不同阶段设置不同动作？→
Phaser的onAdvance()更灵活 - 性能敏感且只做单层同步？→
CyclicBarrier的await()在 HotSpot 下有专门优化路径
别为了“听起来更现代”而换 Phaser——多数批量同步场景里，CyclicBarrier 的简洁性本身就是稳定性保障。
