countdownlatch是轻量级完成信号协调器，仅负责等待，需配合线程安全容器、超时控制、异常兜底和结果聚合使用；初始化count必须严格等于子任务数；子任务须在finally中调用countdown()；主线程await必须带超时并检查返回值；结果汇总依赖concurrenthashmap等线程安全容器。
CountDownLatch 不是任务编排器，而是轻量级的“完成信号协调器”——它只管等，不管结果、不调度、不重试、不传播异常。真正落地多线程协同，必须把它和线程安全容器、超时控制、异常兜底、结果聚合这几块拼在一起用。
初始化数量必须与子任务数严格一致
构造 CountDownLatch 时传入的 count 值，就是你预期会调用 countDown() 的总次数。少设会导致主线程提前唤醒，部分任务还没跑完；多设则可能永久阻塞（除非加超时）。
- 启动前就确定子任务总数，建议用 final int TOTAL_TASKS = tasks.size(); 初始化 latch
- 若使用线程池 submit() 提交任务，需确认任务确实被接收并执行（避免拒绝策略丢任务）
- 调试时可打印 latch.getCount()，快速定位漏减或重复减的问题
每个子任务务必在 finally 中调用 countDown()
countDown() 必须放在 try-finally 块的 finally 里，确保无论任务成功、抛异常、还是被中断，计数器都能被扣减。否则一旦某个子任务异常退出没减，主线程就会卡死。
- 不要在 run() 开头或刚启动时就 countDown()，必须等核心逻辑（如连接建立、数据加载、配置校验）真正完成后再减
- 即使初始化失败，也建议 countDown() —— 主线程后续可通过状态容器判断哪些失败，而非无限等待
- 绝对避免同一个任务多次调用 countDown()，会破坏计数逻辑，导致提前释放或负值
主线程 await 必须带超时且检查返回值
生产环境禁止使用无参 await()。永远用带超时的重载方法，并根据业务预期耗时设定合理阈值（比如初始化场景设 30 秒，IO 密集型任务设 2 分钟）。
- if (!latch.await(30, TimeUnit.SECONDS)) { throw new TimeoutException("初始化超时"); }
- 超时后可主动收集各子任务状态（比如查 ConcurrentHashMap 中已完成/失败项）、记录告警、触发降级流程
- await 被中断时会抛 InterruptedException，需捕获并恢复中断状态：Thread.currentThread().interrupt()
结果汇总靠线程安全容器，不是 CountDownLatch
CountDownLatch 不传值、不存结果、不合并数据。你需要额外选一个线程安全的共享结构来承载子任务输出。
- 推荐 ConcurrentHashMap
存键值结果（key 可为任务 ID 或类型），避免 HashMap 并发写异常 - 若顺序敏感且元素不多，可用 CopyOnWriteArrayList；高频更新场景慎用
- 状态标记类字段（如是否全部成功、错误总数）优先用 AtomicInteger 或 AtomicBoolean，比 synchronized 更轻量
- 主线程 await 返回 true 后，再遍历容器做一致性校验或聚合计算，切勿在未确认 latch 归零前读取结果
