CountDownLatch适用于单向等待、一次性场景，主线程等待工作线程完成；CyclicBarrier适用于对等同步、可重复场景，所有线程互相等待并可循环使用。
CountDownLatch 和 CyclicBarrier 都用于线程协调，但设计目标完全不同：一个管“等别人做完”，一个管“大家一起到齐再走”。
谁在等谁？协作关系决定用哪个
CountDownLatch 是单向等待模型：通常主线程（或少数线程）等待一批工作线程完成任务。比如加载 5 个配置项，每个子线程加载一项，主线程调用 await() 等全部加载完毕才继续；子线程各自调用 countDown() 通知完成。
CyclicBarrier 是对等同步模型：所有参与线程地位相同，彼此互等。比如 4 个计算线程分头处理数据块，每个线程完成自己那部分后调用 await()，必须等第 4 个线程到达，大家才同时放行——没有“主”和“从”之分。
能重复用吗？生命周期差异很关键
CountDownLatch 一旦计数归零，就不可重置。后续调用 await() 直接返回，不再阻塞。它天生适合一次性事件，如服务启动初始化、批量任务收尾汇总。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
立即学习“Java免费学习笔记（深入）”；
CyclicBarrier 在每次触发后自动重置计数器，可立即投入下一轮使用。它还支持传入一个 Runnable 回调，在每次所有线程到齐时由某一线程执行（例如汇总中间结果），这是 CountDownLatch 不具备的能力。
典型场景怎么选？看任务结构
- 用 CountDownLatch 的情况：有明确的“等待方”和“被等待方”，且只需等一次——比如 Web 应用启动时，主线程等数据库连接池、缓存客户端、消息监听器全部就绪后再开放请求入口。
- 用 CyclicBarrier 的情况：多个线程构成固定小组，需分阶段协同推进——比如模拟棋类 AI 对战，每轮双方各自思考、同步落子；或批处理中每轮 10 个线程并行计算 → 汇总 → 清空状态 → 进入下一轮。
容易踩的坑
CountDownLatch 在线程池资源紧张时可能引发死锁：若 await() 调用者和 countDown() 执行者共用同一有限线程池，而所有线程都在 await() 上阻塞，就没有线程能执行 countDown()，导致永久等待。
CyclicBarrier 对中断敏感：任一参与者被中断，整个屏障会进入破损状态（BrokenBarrierException），其余线程 await() 也会立即抛异常，需做好异常捕获与恢复逻辑。
