CountDownLatch在系统启动预加载中的核心价值是等待多个独立异步任务全部完成后再放行主流程，它仅作轻量级门闩，不调度任务、不保证顺序，语义清晰且比CompletableFuture.allOf和awaitTermination更精准适用。
CountDownLatch 在系统启动预加载任务中，核心价值是“等待多个异步初始化任务全部完成后再放行主流程”。它不负责任务调度，也不保证任务执行顺序，只做可靠的“门闩”——所有预加载任务提交后，主线程阻塞等待，直到倒计时归零。
为什么选 CountDownLatch 而不是 CompletableFuture 或线程池 awaitTermination
系统启动时的预加载任务通常具备以下特点：任务彼此独立、无依赖、无需返回结果聚合、只需“全部做完才继续”。CountDownLatch 比 CompletableFuture.allOf 更轻量（无回调开销、无异常包装），比线程池的 awaitTermination 更精准（后者需 shutdown，且无法区分“任务是否真在跑”）。它只关心“数量”，语义清晰，不易误用。
- 初始化缓存、加载配置、建立连接池、预热线程池等任务，适合并行执行但必须全部就绪
- 避免因某个慢任务拖累整体启动，又不能跳过或降级（比如数据库连接失败应中断启动）
- 主线程（如 Spring 的 ApplicationRunner 或 Servlet 容器启动钩子）需要同步感知完成状态
典型使用模式：提交任务 + 等待 + 异常处理
关键不在倒计时设置，而在如何把“任务执行”和“countDown”安全绑定。推荐在每个任务的 finally 块中调用 countDown，防止因异常导致倒计时卡住。
- 创建 CountDownLatch 实例时，参数为预加载任务总数（例如 new CountDownLatch(4)）
- 每个预加载任务提交到线程池后，在其 Runnable/Callable 内部包裹 try-finally，确保 countDown 执行
- 主线程调用 latch.await(timeout, TimeUnit.SECONDS)，超时后应主动检查未完成任务并记录日志
- 若任一任务抛出异常，建议在该任务内捕获并记录，同时仍执行 countDown；由主线程统一判断是否所有任务完成，再决定是否继续启动
与 Spring Boot 集成的实用写法
在 Spring 环境中，可借助 ApplicationRunner 或 InitializingBean，但更推荐用 @PostConstruct + 自定义初始化 Bean，便于单元测试和生命周期控制。
立即学习“Java免费学习笔记（深入）”；
- 定义一个 @Component 初始化 Bean，注入所需服务（如 CacheManager、ConfigService）
- 在方法内构建线程池（建议使用自定义命名前缀的 ThreadPoolTaskExecutor，避免干扰全局线程池）
- 用 CountDownLatch 控制主线程阻塞，而非依赖 Spring 的上下文刷新事件顺序
- 若预加载失败（如 latch.await 返回 false 或统计发现异常），抛出 RuntimeException，触发 Spring 启动失败，防止部分初始化的“半成品”应用上线
容易踩的坑和应对建议
CountDownLatch 是一次性门闩，不可重置。常见问题不是 API 用错，而是任务边界和异常流没理清。
- 忘记在任务中调用 countDown，或在错误位置调用（如放在 if 分支里漏掉 else）→ 统一用 finally 保证执行
- 任务内部又启动了异步子任务但没等它结束就 countDown → 把子任务逻辑也纳入当前任务的执行边界，或改用 CyclicBarrier 处理嵌套等待
- 超时时间设得太短（如 1 秒），而实际加载耗时波动大 → 根据压测结果设定合理 timeout，并预留日志输出未完成任务名称
- 多个模块各自 new CountDownLatch 导致竞争或泄漏 → 推荐将 latch 作为局部变量，作用域严格限制在单次启动流程内
