什么时候该用 CyclicBarrier 而不是 CountDownLatch
当你需要多个线程反复在某个点同步、等彼此都到达后再一起往下走，就该选 CyclicBarrier；CountDownLatch 是一次性倒数，用完就废，没法重用。
典型场景：分段计算后汇总结果（比如 4 个线程各自处理一批数据，算完必须等齐了再合并统计），且这个“分段→等待→合并”流程要跑好几次——这时候 CyclicBarrier 的可重用性才是关键。
-
CyclicBarrier构造时指定参与线程数，到达的线程调用await()阻塞，直到满员才同时放行 - 它支持传入一个
Runnable作为“屏障动作”，在最后一次线程到达、放行前自动执行一次（适合做汇总逻辑） - 如果某线程被中断或超时退出，整个屏障会
broken，后续所有await()都直接抛BrokenBarrierException
await() 抛 BrokenBarrierException 怎么办
这不是偶发异常，而是屏障已被破坏的明确信号——通常因为有线程在 await() 时被中断、超时，或屏障动作里抛了未捕获异常。
重点不是“怎么吞掉它”，而是得立刻检查：是不是某线程卡死、超时设置过短、或屏障动作里写了可能出错的 IO/计算逻辑？
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 别在
catch(BrokenBarrierException)里简单重试，屏障已失效，重试只会再抛一次 - 真要恢复，得新建一个
CyclicBarrier实例（原实例不可复位） - 超时控制建议用
await(long timeout, TimeUnit unit)，避免无限阻塞；但注意：超时本身就会触发BrokenBarrierException - 屏障动作（
Runnable）里务必包住异常，否则会导致屏障直接 broken
屏障动作里做汇总，为什么结果总是少一部分
因为屏障动作只由**最后一个到达的线程**执行一次，不是每个线程都执行。如果你在动作里只读了那个线程自己的局部变量，自然拿不到别人算的结果。
正确做法是：所有线程把中间结果写到共享容器（如 ConcurrentHashMap、AtomicIntegerArray 或预分配好的数组），屏障动作再统一读取汇总。
- 别用普通
ArrayList或HashMap，多线程写会出错 - 如果用数组，确保索引和线程一一对应（比如线程 ID 对应数组下标），避免覆盖
- 屏障动作里不要做耗时操作（如写文件、网络请求），否则会拖慢所有线程释放时间
和 ForkJoinPool + RecursiveTask 比，该选哪个
如果任务天然可递归拆分（比如归并排序、树遍历），且子任务量级差异不大，ForkJoinPool 更省心；CyclicBarrier 更适合“固定分组、显式协同”的场景，比如 8 个线程各负责一个数据库分片，查完必须等齐再做关联。
-
CyclicBarrier不管理线程生命周期，你得自己维护线程池（推荐ThreadPoolExecutor） -
ForkJoinPool默认使用工作窃取，对不均衡任务更友好；CyclicBarrier要求你手动保证各线程工作量接近，否则快的线程会早到、干等 - 没有“嵌套屏障”这种东西——想实现多层同步，得套多个
CyclicBarrier实例，逻辑容易绕晕
真正难的不是调用 await()，是设计好线程间的数据交接方式和错误传播路径。屏障一旦 broken，整个协同链条就断了，得从共享状态和超时策略上提前兜底。
