cyclicbarrier.await()卡住是因为未凑够指定线程数，必须所有参与线程均调用await()才集体放行；少一个则其余全部阻塞。
为什么 CyclicBarrier.await() 会卡住不返回
多数人第一次用 CyclicBarrier 卡在 await()，不是代码写错了，而是没凑够线程数。它必须等所有参与线程都调用一次 await()，才会集体放行；少一个，其余全部阻塞。
常见错误现象：Thread-0 和 Thread-1 已调用 await()，但主线程没参与或提前退出，导致两个子线程永远挂起。
- 确认构造时传入的 parties 数（比如
new CyclicBarrier(3)）和实际调用await()的线程数严格一致 - 避免在循环中重复创建
CyclicBarrier实例——它本就支持复用，新建等于重置计数，旧等待直接失效 - 注意异常分支：某个线程抛出
BrokenBarrierException或被中断后，屏障自动进入 broken 状态，后续所有await()都立即抛该异常，不会等
如何安全复用 CyclicBarrier 做多轮并行计算
CyclicBarrier 的“Cyclic”就体现在这里：一轮结束后可立刻开始下一轮，不需要重建对象。但前提是上一轮没被破坏（即没触发 BrokenBarrierException 或调用 reset()）。
使用场景：分批处理大数据集，每批 4 个线程并行计算，批间需同步结果再继续。
立即学习“Java免费学习笔记（深入）”；
- 每轮开始前检查状态，用
isBroken()判断是否还能用；若已损坏，必须新建实例 - 不要在
Runnable回调（即barrierAction）里做耗时操作——它由最后一个到达的线程串行执行，会拖慢整轮完成时间 - 如果某轮有线程中途失败（如计算异常），建议显式调用
reset()清理状态，否则下一轮可能因残留 broken 状态直接失败
示例：启动 3 个线程跑两轮，第二轮前加 if (barrier.isBroken()) barrier = new CyclicBarrier(3);
CyclicBarrier vs CountDownLatch：选错就白忙活
两者都用来协调线程，但语义完全不同。CountDownLatch 是“单次倒计时门禁”，适合一个线程等多个任务结束；CyclicBarrier 是“多线程互相等彼此”，适合多点协同推进。
典型误用：用 CountDownLatch 实现各线程算完再一起读共享变量——结果是读操作分散在不同时间点，根本不同步。
- 需要“所有线程都到达某点后，才同时往下走”，必须用
CyclicBarrier -
CountDownLatch的countDown()可由任意线程调用，CyclicBarrier.await()必须由参与同步的线程自己调 - 性能上无显著差异，但逻辑错位会导致结果不可预测，比性能问题更致命
带超时的 await() 怎么设才合理
await(long timeout, TimeUnit unit) 不是万能保险，设太短会频繁报 TimeoutException，设太长又掩盖真实卡死问题。
关键在理解超时单位：它从当前线程调用 await() 开始计时，不是从第一人到达开始。所以超时值必须大于「最慢线程到达 + 执行 barrierAction（如果有）」的预期耗时。
- 调试期建议先用无参
await()定位是否真卡住；上线后再加超时，并记录TimeoutException上下文（比如当时已到达几个线程） - 超时后线程会抛异常并继续执行，但屏障仍处于 broken 状态，其他线程后续
await()也会立即失败 - 别依赖超时来“跳过同步”——这等于放弃一致性，多点计算结果可能错乱
真正难处理的是“部分线程卡死、部分已超时退出”的混合态，这时屏障状态混乱，通常只能重建实例并重试整组计算。
