什么时候该用 CyclicBarrier 而不是 CountDownLatch

当你需要多个线程反复在某个点同步、等彼此都到达后再一起往下走，就该选 CyclicBarrier；CountDownLatch 是一次性倒数，用完就废，没法重用。

典型场景：分段计算后汇总结果（比如 4 个线程各自处理一批数据，算完必须等齐了再合并统计），且这个“分段→等待→合并”流程要跑好几次——这时候 CyclicBarrier 的可重用性才是关键。

• CyclicBarrier 构造时指定参与线程数，到达的线程调用 await() 阻塞，直到满员才同时放行
• 它支持传入一个 Runnable 作为“屏障动作”，在最后一次线程到达、放行前自动执行一次（适合做汇总逻辑）
• 如果某线程被中断或超时退出，整个屏障会 broken，后续所有 await() 都直接抛 BrokenBarrierException

await() 抛 BrokenBarrierException 怎么办

这不是偶发异常，而是屏障已被破坏的明确信号——通常因为有线程在 await() 时被中断、超时，或屏障动作里抛了未捕获异常。

重点不是“怎么吞掉它”，而是得立刻检查：是不是某线程卡死、超时设置过短、或屏障动作里写了可能出错的 IO/计算逻辑？

• 别在 catch(BrokenBarrierException) 里简单重试，屏障已失效，重试只会再抛一次
• 真要恢复，得新建一个 CyclicBarrier 实例（原实例不可复位）
• 超时控制建议用 await(long timeout, TimeUnit unit)，避免无限阻塞；但注意：超时本身就会触发 BrokenBarrierException
• 屏障动作（Runnable）里务必包住异常，否则会导致屏障直接 broken

屏障动作里做汇总，为什么结果总是少一部分

因为屏障动作只由**最后一个到达的线程**执行一次，不是每个线程都执行。如果你在动作里只读了那个线程自己的局部变量，自然拿不到别人算的结果。

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

正确做法是：所有线程把中间结果写到共享容器（如 ConcurrentHashMap、AtomicIntegerArray 或预分配好的数组），屏障动作再统一读取汇总。

• 别用普通 ArrayList 或 HashMap，多线程写会出错
• 如果用数组，确保索引和线程一一对应（比如线程 ID 对应数组下标），避免覆盖
• 屏障动作里不要做耗时操作（如写文件、网络请求），否则会拖慢所有线程释放时间

和 ForkJoinPool + RecursiveTask 比，该选哪个

如果任务天然可递归拆分（比如归并排序、树遍历），且子任务量级差异不大，ForkJoinPool 更省心；CyclicBarrier 更适合“固定分组、显式协同”的场景，比如 8 个线程各负责一个数据库分片，查完必须等齐再做关联。

• CyclicBarrier 不管理线程生命周期，你得自己维护线程池（推荐 ThreadPoolExecutor）
• ForkJoinPool 默认使用工作窃取，对不均衡任务更友好；CyclicBarrier 要求你手动保证各线程工作量接近，否则快的线程会早到、干等
• 没有“嵌套屏障”这种东西——想实现多层同步，得套多个 CyclicBarrier 实例，逻辑容易绕晕

真正难的不是调用 await()，是设计好线程间的数据交接方式和错误传播路径。屏障一旦 broken，整个协同链条就断了，得从共享状态和超时策略上提前兜底。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南