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