CountDownLatch 是一次性同步辅助类，用于让线程等待其他线程完成指定数量的操作；典型场景包括主线程等待多个子任务结束、测试并发起跑线、多异步初始化完成等。
CountDownLatch 是什么，什么时候该用它
CountDownLatch 是一个一次性同步辅助类，核心作用是让一个或多个线程等待，直到其他线程完成一组操作。它不用于保护共享资源，也不替代 synchronized 或 ReentrantLock；它的典型场景是「等全部任务做完再继续」，比如：
- 主线程启动多个子任务后，统一等待它们全部结束
- 测试中模拟并发请求到达的“起跑线”
- 初始化阶段依赖多个异步加载项完成
它内部维护一个计数器，调用 countDown() 递减，调用 await() 的线程会阻塞直到计数器归零。计数器归零后，所有等待线程被唤醒，且后续再调用 await() 会立即返回——它不可重置，用完即弃。
怎么正确初始化和触发等待
构造时必须传入正整数作为初始计数：new CountDownLatch(3) 表示要等 3 次 countDown()。常见错误包括：
- 传入 0：虽然合法，但
await()立即返回，容易掩盖逻辑误判 - 计数与实际任务数不一致：比如启动了 5 个线程却只
countDown()4 次，主线程永远卡在await() - 在非预期位置调用
countDown()：例如在异常分支遗漏调用，导致计数无法归零
推荐写法是在每个任务执行完毕（无论成功或失败）后确保调用 countDown()，通常放在 finally 块里：
立即学习“Java免费学习笔记（深入）”；
executor.submit(() -> {
try {
doWork();
} finally {
latch.countDown(); // 保证计数一定减少
}
});
await() 要不要加超时？为什么
无参 await() 会无限等待，一旦漏调 countDown() 或某个任务卡死，整个流程就挂住。生产环境强烈建议使用带超时的版本：latch.await(10, TimeUnit.SECONDS)。
- 返回
true表示计数已归零，可安全继续 - 返回
false表示超时，此时应主动处理：记录告警、中断任务、清理资源 - 超时单位别写错：
TimeUnit.MILLISECONDS和TimeUnit.SECONDS差 1000 倍，容易误判
注意：超时后 await() 返回 false，但计数器状态不变；如果之后别的线程又调了 countDown() 归零，不会重新唤醒已超时返回的线程——它已经走完了。
和 CyclicBarrier、Phaser 有什么关键区别
选错工具会导致逻辑难维护或行为异常：
-
CyclicBarrier可重复使用，适合多轮协作（如多轮计算迭代），且支持到达时触发Runnable动作；而CountDownLatch一旦触发就失效 -
Phaser更灵活，能动态增删参与者、分阶段等待，但复杂度高；简单“等 N 件事做完”场景，CountDownLatch更轻量、语义更清晰 - 它们都不解决线程安全问题：如果多个线程共用同一份结果容器（如
ArrayList），仍需额外同步机制
别为了“看起来高级”硬套 Phaser，多数初始化等待、批量任务汇合场景，CountDownLatch 就是最直接的选择。真正容易被忽略的是：它不传递异常，子线程抛出的异常不会自动冒泡到 await() 调用方，得靠额外机制（比如 Future.get() 或共享 AtomicReference<throwable></throwable>）捕获。
