CountDownLatch构造参数应填需调用countDown()的总次数而非线程数；必须在finally中调用countDown()；await()务必加超时；它是一次性且不支持结果聚合，适用场景有限。

CountDownLatch 构造参数填多少？别硬算任务数

构造 CountDownLatch 时传的数字，不是“要等几个线程”，而是“要被 countDown() 几次才放行”。常见错误是把线程数当计数值，结果任务没跑完就提前唤醒了。

• 如果用固定线程池执行 5 个任务，每个任务末尾调一次 countDown()，那构造时填 5
• 如果某个任务内部会分叉出多个子任务（比如 fork/join 或异步回调），且你希望所有子任务都完成才算“该任务结束”，那得手动控制 countDown() 的时机——不能依赖线程数量
• 构造后无法重置，要复用必须新建实例；别在循环里反复 new 同一个 latch 却忘了重置逻辑

await() 要不要加超时？几乎 always 要

不带超时的 await() 是阻塞死等，一旦某个任务抛异常没调 countDown()，主线程就永远卡住。生产环境基本没理由不用超时版本。

• 推荐写法：latch.await(30, TimeUnit.SECONDS)，超时后检查 latch.getCount() 判断还有几个没完成
• 超时返回 false 不等于失败，只是“还没等到全部完成”，后续仍可继续等待或做兜底处理
• 注意：超时单位别写错，TimeUnit.MILLISECONDS 和 SECONDS 混用会导致等 1000 倍时间或瞬间超时

countDown() 放在哪？别放在 try-catch 外围

很多新手把 countDown() 写在任务逻辑最后，但一旦中间抛 RuntimeException 或 InterruptedException，这句就根本不会执行，latch 永远不会归零。

JavaStoryDevelop

你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在

下载

• 必须包在 finally 块里，哪怕任务失败也要计数减一
• 错误示范：

  doWork(); countDown();

  → 正确写法：

  try { doWork(); } finally { latch.countDown(); }

• 如果任务本身支持取消（如用了 Future.cancel()），也要确保 cancel 后仍触发 countDown()，否则 latch 可能漏减

和 CyclicBarrier、CompletableFuture 比有什么坑？

CountDownLatch 是一次性门闩，用完即弃；它不关心参与者身份，也不合并结果。这点和 CyclicBarrier（可重用、支持 barrier action）或 CompletableFuture.allOf()（能聚合异常、支持链式处理）有本质区别。

立即学习“Java免费学习笔记（深入）”；

• 需要多次等待同一批任务？别硬复用 CountDownLatch，改用 CyclicBarrier 或每次 new 新实例
• 要等完之后统一处理每个任务的返回值？CountDownLatch 不提供这个能力，得自己用 ConcurrentHashMap 存结果，或者直接上 CompletableFuture
• 任务之间有依赖关系（B 要等 A 结果）？CountDownLatch 无法表达这种拓扑，强行用只会让代码变成状态机地狱

实际用的时候，最常被忽略的是：latch 的生命周期和任务生命周期是否真正对齐。尤其在异步回调、线程池拒绝策略、JVM 关闭钩子等场景下，countDown() 可能根本没机会执行——这时候光靠超时检测还不够，得配合外部健康检查或日志埋点。