CountDownLatch是一次性倒计时门闩，主线程等待子线程完成；CyclicBarrier是可重用循环栅栏，所有线程互相等待至屏障点后同步放行，支持多轮迭代与触发回调。
CountDownLatch 和 CyclicBarrier 看似都是“等线程”，但协作逻辑完全不同：前者是单向等待，后者是双向同步；一个是一次性门闩，一个是可复用栅栏。选错工具，轻则逻辑卡死，重则任务漏执行。
协作关系不同：谁在等谁？
CountDownLatch 是主线程等子线程完成——比如老师收齐全班作业才批改，学生之间互不等待、各干各的；子线程调用 countDown() 递减计数器，主线程调用 await() 阻塞直到归零。
CyclicBarrier 是所有线程互相等待——比如五人小组做实验，每人负责一步，必须全部站到操作台前，才一起按下启动键；每个线程都调用 await()，第 N 个到达者触发集体放行。
简单说：
– CountDownLatch：1 个（或多个）等待者 + N 个执行者
– CyclicBarrier：N 个平等参与者，彼此都是等待者，也都是被等待者
生命周期不同：能重复用吗？
CountDownLatch 不可重置。一旦计数器减到 0，await() 立即返回，后续再调用也不会阻塞——它天生为“一次性事件”设计，如服务启动时加载配置、初始化资源。
立即学习“Java免费学习笔记（深入）”；
CyclicBarrier 可自动重用。屏障被触发后，内部计数器立刻重置为初始值，下一轮 await() 仍有效——适合多轮迭代场景，例如：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 分批次处理大数据：每批 10 个线程计算 → 汇总 → 清空状态 → 进入下一批
- 游戏房间匹配：玩家陆续加入，满 4 人就开局；一局结束，同一组线程可立即准备下一局
它还支持可选的 Runnable 回调，在每次屏障触发时由某一线程执行（如汇总结果），这是 CountDownLatch 不具备的能力。
异常与中断行为不同：出错了怎么处理？
CountDownLatch 的 await() 被中断时抛 InterruptedException，但计数器状态不变，其他线程仍可继续 countDown()；只要最终归零，剩余等待线程仍能通过。
CyclicBarrier 更敏感：任一参与线程在 await() 时被中断、超时或抛出未捕获异常，整个屏障就会被打破（broken）。此时所有已阻塞和后续调用 await() 的线程都会收到 BrokenBarrierException，必须显式调用 reset() 才能恢复使用——这既是约束，也是对协同一致性的强保障。
怎么选？看这三个问题
快速判断该用哪个：
- 是否需要多轮重复等待？→ 是 → 选 CyclicBarrier
- 是否只有部分线程在等，其余只干活不等待？→ 是 → 选 CountDownLatch
- 是否要求所有参与者严格同步节奏（比如同时开始下一步）？→ 是 → 选 CyclicBarrier
补充提醒：高并发下慎用 CountDownLatch 做“多线程同时起跑”——若用在固定大小线程池中，可能因 await 占用线程导致死锁；而 CyclicBarrier 天然适合这种“齐步走”模型。
