如何在 Java 中使用 java.util.concurrent.CountDownLatch 让主线程等待多个并行初始化任务完成

CountDownLatch 用起来有几个硬性要求：初始化时必须传正整数，传0的话它会直接判定为已完成，await() 根本不会阻塞；传负数则直接抛出 IllegalArgumentException。任务数量得提前定好，不能中途改。countDown() 必须放在 finally 块里调用；await() 最好用带超时的版本，同时要处理中断和返回值。最关键的一点：它是一次性组件，用完不能重置。

CountDownLatch 构造时必须传入正整数

你可能会想，传入0会怎样？结果是它立刻被标记为“已完成”，await() 根本不会等你。传负数就更干脆，直接抛 IllegalArgumentException。所以，任务数量必须在启动前定好，而且不能动态增减。

最常见的坑是算错任务数——比如用 list.size() 时没校验 list 是否为 null，或者在循环里不小心多调了一次 countDown()，结果主线程被过早释放。

• 初始化时确保传入的值等于实际要等待的子任务数
• 避免在任务未真正启动前就调用 countDown()
• 不要在同一个 CountDownLatch 实例上多次调用 await() 后又复用——它不可重置

每个子任务必须在 finally 块里调用 countDown()

这里藏着最常踩的坑。子任务可能因为异常、超时或某个逻辑分支提前退出，如果你只在正常流程末尾写 countDown()，那主线程就会永远卡在 await() 上，谁也救不了。

典型场景：用 ExecutorService 提交多个 Runnable，每个都负责初始化一个组件——比如数据库连接池或缓存客户端。哪怕某个初始化抛了 RuntimeException，也得保证计数器减一。

executor.submit(() -> {    try {        initDatabase();    } catch (Exception e) {        log.error("DB init failed", e);    } finally {        latch.countDown(); // 关键：必须放 finally    }});

await() 要处理超时和中断

生产环境里，不能让主线程无限等下去。如果某个子任务卡死或网络异常，await() 的无参版本会让整个应用 hang 住。必须用带超时的重载，并且检查返回值。

另外，主线程若被中断（比如容器发来 shutdown 信号），await(long, TimeUnit) 会返回 false，这时候应该主动清理已初始化成功的资源，而不是继续傻等。

• 优先使用 latch.await(30, TimeUnit.SECONDS)，别用 latch.await()
• 返回 false 表示超时，此时需要判断哪些子任务已完成、哪些失败，再决定是否继续启动主服务
• 如果主线程被中断，await() 会抛 InterruptedException，记得重设中断状态：Thread.currentThread().interrupt()

CountDownLatch 不适合需要重复使用的场景

它是一次性的——一旦计数归零，所有后续 await() 都会立即返回 true，没法回到初始状态。如果你的初始化逻辑要支持热重载或周期性 reload，别硬套 CountDownLatch。

这时候更合适的是 CyclicBarrier（支持重置），或者手动管理状态加 ReentrantLock 和 Condition。不过要注意，CyclicBarrier 的语义是“所有线程互相等待到达某一点”，不是“主线程等子线程”，用法和协作模型完全不同。

简单说：只要需求是“一个线程等 N 个异步操作结束”，CountDownLatch 就是对的；但凡要第二次用，就得新建实例，别想着 reset。