CountDownLatch 初始化需严格匹配组件数、finally 中必调 countDown、await 必带超时并处理三种返回值，且各组件须在 init 内自检健康状态。
CountDownLatch 协同多线程完成复杂初始化，关键不是“等完就完事”，而是让主线程可靠地感知所有组件是否真正就绪——它不验证健康状态，只确认“已执行完毕”。用对了，系统启动稳；用错了，要么卡死、要么带病上线。
初始化数量必须提前锁定且严格匹配
构造 CountDownLatch 时传入的数字，必须等于实际要并发初始化的组件个数，且这个数不能动态变化。比如数据库连接池、Redis 客户端、MQ 消费者共 3 个，就得写 new CountDownLatch(3)。
- 传 0：await() 立即返回，主线程跳过等待，后续逻辑可能因依赖未就绪而 NPE
- 传负数：直接抛
IllegalArgumentException - 传多（如该 3 写成 5）：主线程永远 await，除非设超时，否则表现为“启动卡住”
- 传少（如该 3 写成 2）：主线程提前唤醒，部分组件还在初始化中，服务已对外暴露
建议在提交任务前校验集合非空，并把任务数存为 final 变量，避免 list.size() 调用时为空或被修改。
每个组件必须在 finally 中调用 countDown()
countDown() 不是“初始化成功才减”，而是“无论成败、无论是否抛异常、是否超时，只要该组件的初始化流程走完了，就必须减一”。漏掉一次，主线程就永远阻塞。
立即学习“Java免费学习笔记（深入）”；
- 推荐结构：用 ExecutorService 提交 Runnable，在 try 块里执行 init()，finally 块里调用
latch.countDown() - 即使 init() 抛出 RuntimeException 或 TimeoutException，也要确保计数器递减
- 不要在 run() 开头或线程刚启动时就 countDown()，那只是“开始”，不是“完成”
主线程 await 必须带超时并区分三种结果
生产环境绝不能用无参 await()。必须使用 latch.await(30, TimeUnit.SECONDS) 这类带超时的调用，并根据返回值做不同处理：
- 返回
true：全部组件已完成 countDown()，可进入启动阶段 - 返回
false：超时，此时应主动关闭已成功初始化的组件（如 close DataSource、shutdown RedisClient），再抛出 InitializationException - 抛
InterruptedException：需立即恢复中断状态Thread.currentThread().interrupt()，并终止初始化流程
初始化完成 ≠ 组件可用，关键组件要自检
CountDownLatch 只保证“每个组件都调用了 countDown()”，不保证连接通、配置对、资源足。例如 DB 连接池可能建连成功但没 validate，Redis 客户端可能连上了却无法执行命令。
- 应在各组件自己的
init()方法内部完成最小可行性检查，比如执行SELECT 1或PING - 自检失败时仍要调用 countDown()，但记录错误信息供主线程汇总判断
- 可搭配
ConcurrentHashMap<String, InitResult>收集各组件状态，await 返回 true 后统一校验是否全部 healthy
