CountDownLatch适用于“一次等待全部完成”，计数器归零后不可重置；CyclicBarrier适用于“多轮同步起跑”，可重复使用，每轮等待固定数量线程到达后自动重置。
CountDownLatch 适合“一次等全部完成”
它就像发令枪——主线程调用 await() 后就卡住，直到所有工作线程都调用过 countDown() 把计数器减到 0。一旦归零，所有等待线程立刻唤醒，且这个 CountDownLatch 就废了，不能再 await() 或重置。
常见错误现象：await() 永远不返回，大概率是漏调了 countDown()，或者某线程异常退出没执行到那行；也可能是构造时传的初始值比实际工作线程数少，导致计数器提前归零、部分线程根本没被等。
- 初始化值必须等于「预期会调用
countDown()的线程总数」，不是启动的线程数（比如有些线程可能跳过任务） -
countDown()可在任意线程中安全调用，不限于创建它的线程 - 性能上无额外锁开销，底层靠 AQS 的 CAS + volatile state 实现，轻量
CyclicBarrier 适合“多轮同步起跑”
它像接力赛的交接区——每轮都有固定数量的线程到达后，才一起放行；之后计数器自动重置，下一轮还能用。关键区别在于：它不关心“谁先干完”，只关心“谁到了”，而且支持复用。
使用场景典型如分批处理：100 条数据分 5 组，每组 20 条由一个线程处理；每组处理完，必须等其他 4 组也完成，才能统一写库或触发下阶段计算。
- 构造时传的
parties是每轮必须到达的线程数，不是总线程数 - 任意线程调用
await()都可能触发屏障释放（取决于谁是最后一个），该线程会执行barrierAction（如果设置了） - 若某线程中断或抛出未捕获异常，其他等待线程会收到
BrokenBarrierException，屏障即失效，需重建实例
别混用：它们的语义和生命周期完全不同
CountDownLatch 是“终点线”，CyclicBarrier 是“集合点”。前者强调结果导向（任务是否全做完），后者强调过程协同（大家是否同时到位）。
参数差异直接暴露设计意图：CountDownLatch(int count) 的 count 是倒计时起点；CyclicBarrier(int parties) 的 parties 是每轮参与人数阈值——名字里就藏着不可互换的逻辑。
- 想等异步 IO 全部返回再汇总？用
CountDownLatch - 想让 4 个计算线程每轮都同步读取最新中间状态再继续？用
CyclicBarrier - 误把
CyclicBarrier当CountDownLatch用（比如只调一次await()就不管了），等于白加一层阻塞，还可能因未重用而泄漏资源
容易被忽略的细节：异常传播与重用边界
两者对异常的反应截然不同：CountDownLatch.await() 只会响应线程中断（抛 InterruptedException），不影响其他等待者；而 CyclicBarrier.await() 一旦某个线程因中断/超时/异常退出，整个屏障就崩了，所有等待线程都会收到 BrokenBarrierException —— 这不是 bug，是设计使然，意味着“本轮同步已不可靠”。
复用性也不是免费的：CyclicBarrier 虽可循环，但每次 await() 返回后，内部 count 重置为 parties，不代表线程安全地“准备好下一轮”——如果某线程还没从上一轮 await() 返回，就提前开始下一轮逻辑，可能引发状态错乱。
