CountDownLatch 正确用法是：countDown() 必须在每个子任务的 finally 块中调用且仅一次，await() 放在主线程需阻塞处并建议设超时；它是一次性计数器，不可重用，与 join()（线程级硬等待）和 CyclicBarrier（可重置同步点）有本质区别。
CountDownLatch 怎么用才不会卡死主线程
核心就一条：countDown() 必须在所有需要等待的子任务里被调用，且只调用一次；await() 要放在真正需要阻塞的位置，比如主线程里等全部子线程完成。
常见错误是某个子线程抛了异常没走到 countDown()，导致 await() 永远不返回。别指望 JVM 自动帮你补漏。
- 务必把
countDown()放在finally块里，哪怕任务中途失败也要减一 -
await()可以带超时参数，比如await(10, TimeUnit.SECONDS)，避免无限等待 - 不要在同一个
CountDownLatch实例上调用多次await()期望“重用”——它是一次性的，用完就归零，再 await 会立刻返回
为什么不能用 join() 替代 CountDownLatch
join() 是线程级别的硬等待，只能等一个特定线程结束；CountDownLatch 是逻辑计数器，关注的是“N件事做完”，和线程数量、生命周期无关。
典型场景：你启了 5 个 ExecutorService 提交的任务，它们可能跑在不同线程池线程上，甚至复用同一线程。这时 join() 完全无用——你根本没持有所谓的“子线程引用”。
立即学习“Java免费学习笔记（深入）”；
- 用
CountDownLatch时，你只关心“5 个 HTTP 请求都返回了”，不管它们是谁发的、在哪跑的 -
join()要求你持有Thread对象，而线程池场景下你通常只拿到Future - 性能上没差别，但语义清晰度差很多：
join()是“等线程死”，CountDownLatch是“等条件满足”
CountDownLatch 和 CyclicBarrier 的关键区别在哪
最直白的区别：CountDownLatch 是“单次门禁”，打开后就失效；CyclicBarrier 是“可重置路障”，能反复拦人。
如果你的任务是“启动 3 个服务，全部 ready 后一起开始处理请求”，那 CyclicBarrier 更合适，因为后续可能还要“全部完成一批 batch 后再同步下一轮”。而 CountDownLatch 只适合“等初始化全部完成，之后不再协调”这种一次性流程。
-
CountDownLatch构造时传初始计数，countDown()减，await()等零 -
CyclicBarrier构造时传参与方数量，每个线程调await()才计数，触发后自动重置 - 如果某线程在
CyclicBarrier.await()时中断或超时，整个屏障会被打破（所有等待线程收到BrokenBarrierException），而CountDownLatch不会传播这种中断影响
await() 超时后还能继续用这个 CountDownLatch 吗
不能。只要 await() 返回（不管是等到了还是超时了），这个 CountDownLatch 就已进入终态：内部计数为 0，后续所有 await() 都会立即返回 true 或 false（取决于是否超时），countDown() 也不再有效。
这意味着：超时不是“重试信号”，而是“这次协调失败了”。你得自己判断要不要重来——比如新建一个 CountDownLatch(3)，重新分发任务。
- 别试图通过反射重置内部计数器，那是未公开实现细节，不同 JDK 版本行为可能不一致
- 如果业务要求“最多等 5 秒，超时也往下走”，那就直接用
await(5, TimeUnit.SECONDS)，然后检查返回值 - 超时后记得清理资源，比如取消还没完成的
Future，否则可能造成连接泄漏或线程堆积
最常被忽略的一点：CountDownLatch 本身不保证任务执行结果的正确性，它只管“有没有做完”。你要自己处理子任务里的异常、重复提交、状态不一致这些问题——它只是同步的骨架，不是事务的保险丝。
