CountDownLatch是轻量级完成信号协调器，仅解决“等齐”问题：主线程等待所有子任务调用countDown()后被唤醒；需配合线程安全容器、超时控制、异常兜底和结果聚合才能构成完整编排。
CountDownLatch 在多任务异步执行中，不是任务编排器，而是完成信号协调器——它不调度、不传值、不重试、不合并结果，只解决一个核心问题：“等齐”：让主线程可靠地等待一组子任务全部抵达完成状态。
它解决的是“同步时机”问题，而非“任务流程”问题
当多个子任务并行启动（比如加载配置、连接数据库、拉取远程数据），主线程不能靠 sleep() 硬等，也不能靠轮询 getCount() 浪费 CPU。CountDownLatch 提供了一种轻量、原子、阻塞可中断的等待机制：只要所有子任务都调用了 countDown()，主线程就能被精准唤醒。这避免了竞态和误判，是编排“等待点”的基础设施。
必须配合其他组件才能构成完整编排
单独用 CountDownLatch 无法完成真实业务编排，它只是拼图中的一块：
- 任务分发：靠 ExecutorService 或手动 new Thread 启动子任务
- 结果收集：靠 ConcurrentHashMap、ConcurrentLinkedQueue 等线程安全容器承载各子任务输出
- 异常处理：子任务需在 finally 中 countDown()，主线程 await 必须带超时，并检查返回值是否为 true
- 状态反馈：超时后可通过共享容器查哪些任务失败、哪些成功，支撑降级或重试决策
初始化与调用必须严格匹配
计数器初始值 = 实际执行的子任务数，缺一不可：
立即学习“Java免费学习笔记（深入）”；
- 少设 → 主线程提前唤醒，部分任务还在跑，结果不全
- 多设 → 计数器卡在正数，await 永久阻塞（除非加超时）
- 重复调用 countDown() → 计数器变负，语义失效，可能引发逻辑错乱
- 漏调 countDown() → 主线程永远等不到 0，典型死锁场景
适合“一次性等待”型编排场景
它天然适用于启动期、初始化期这类单次、不可重置的协调需求：
- 微服务启动时，等待所有模块（缓存、MQ、定时任务）就绪后再开放 HTTP 接口
- 批量数据导入时，等所有分片写入完成，再统一提交事务或触发通知
- 前端聚合接口中，等待用户信息、订单列表、优惠券三个远程调用全部返回后再组装响应
不适合循环复用或动态增减任务数的场景（此时应考虑 CyclicBarrier 或 CompletableFuture 组合）。
