CountDownLatch不可重用因其state归零后无重置逻辑，而CyclicBarrier通过generation与count双状态实现自动重置；前者适用于一次性等待（如主线程等子任务完成），后者适合多轮协同（如分阶段并行计算）。

CountDownLatch 不能重复使用，这是它的核心设计限制；而 CyclicBarrier 天然支持重用，但二者语义和适用场景不同——直接替换需谨慎，关键在于明确“等待所有线程到达”这一协作模式是否真正匹配业务需求。

理解本质差异：不是“换一个类”，而是“换一种同步逻辑”

CountDownLatch 是“计数器+门闩”模型：初始化后递减，归零即放行，之后永远保持开放状态，不可重置。它适合“一个线程等待多个操作完成”（如主线程等所有子任务结束）。

CyclicBarrier 是“栅栏+循环”模型：每个参与者调用 await() 后阻塞，直到指定数量的线程全部到达，才同时唤醒并重置计数——这才实现“可重复”。它适合“多个线程相互等待、协同进入下一阶段”（如多线程分片计算后统一汇总）。

若原逻辑是“主线程等 5 个异步任务执行完”，强行改用 CyclicBarrier 需让那 5 个任务线程也调用 await()，这往往违背原有职责划分，反而增加耦合。

真正需要“重复等待”时，CyclicBarrier 的正确用法

当场景确实是多线程周期性地“齐步走”（例如：每轮执行采集 → 计算 → 同步 → 下一轮），CyclicBarrier 才是自然选择：

• 构造时指定参与方数量（如 new CyclicBarrier(5)），所有线程共用同一个实例
• 每个线程在阶段交汇点调用 barrier.await()，任意线程被中断或超时会触发 BrokenBarrierException，整个栅栏进入破损状态，需重建
• 可选传入 Runnable 作为“屏障动作”，在最后第 N 个线程到达时、所有线程被唤醒前执行（常用于汇总、日志、清空缓存等）
• 调用 reset() 可手动打破并重置栅栏（但会中断所有等待线程，慎用）

如果只是想“多次等待不同批次任务”，更合适的替代方案

并非所有“重复使用”诉求都该转向 CyclicBarrier。常见替代思路：

• 每次新建 CountDownLatch：简单、无状态、无风险。适用于任务批次独立、无需跨批次共享状态的场景（如反复启动一批 HTTP 请求并等待全部返回）
• 用 CompletableFuture + allOf：函数式风格，链式组合清晰，天然支持异常处理与后续动作，适合异步编排（如 CompletableFuture.allOf(f1, f2, f3).join()）
• 自定义可重置 latch（不推荐）：虽可通过继承或包装实现 reset 功能，但易引入竞态、状态混乱，且失去 JDK 原生实现的优化保障

迁移检查清单：从 CountDownLatch 切换前务必确认

避免因语义误用导致死锁或行为异常：

• 所有参与等待的线程是否都能、且应该调用 await()？还是仅有一个“观察者”线程？
• 是否要求所有线程在到达后“同时继续执行”？还是只需“某个线程确认全部完成即可”？
• 是否有“某轮失败则整轮中止”的需求？CyclicBarrier 的破损机制比 CountDownLatch 的单次失效更严格
• 是否依赖 CountDownLatch 的 countDown() 由非等待线程调用？CyclicBarrier 没有对应能力