CountDownLatch.await(timeout)返回值仅表示是否在超时前计数归零，而非任务成功与否；返回false仅说明等待超时，子任务仍可能继续执行，需配合中断机制或结果容器判断实际状态。
CountDownLatch.await(timeout) 的返回值不是“成功/失败”，而是“是否等到归零”
很多人一看到 await(5, TimeUnit.SECONDS) 返回 false，就立刻认为“任务失败了”，进而抛异常或中断流程。这是错的。返回 false 只说明：在 5 秒内，countDown() 没有把计数减到 0；但其他线程可能还在跑、甚至几毫秒后才调用 countDown() —— 此时主线程已退出等待，无法感知后续变化。
这意味着你不能靠 await() 的返回值判断子任务本身是否成功，只能判断“聚合等待”这个动作有没有在时限内完成。子任务的执行状态，得靠各自返回值、异常捕获或共享结果容器来收集。
-
await()返回true→ 所有countDown()已发生（不保证子任务没抛异常） -
await()返回false→ 主线程放弃等待，但子任务线程仍可能存活并继续执行 - 若需强制终止子任务，必须配合
Thread.interrupt()或使用ExecutorService.shutdownNow()，CountDownLatch本身不提供取消能力
超时值不能简单设为“单个任务耗时 × 任务数”
比如 3 个 HTTP 调用，每个预期 1s，就设 await(3, SECONDS)？危险。网络请求是并行发起的，理论上最大耗时取决于最慢那个，不是总和。更合理的是按 P95 延迟 + 安全余量设上限，例如单个接口 P95 是 800ms，3 个并发则设 await(1200, MILLISECONDS) 即可。
- 超时太短 → 频繁触发假超时，掩盖真实慢依赖
- 超时太长 → 失去超时意义，阻塞主流程太久
- 建议在日志中同时记录
latch.getCount()和耗时，用于事后分析未归零原因（是某个服务卡死？还是根本没触发countDown()？）
countDown() 必须放在 finally 块里，且不能被异常吞掉
这是最容易出问题的地方。如果子任务里发生 NullPointerException 或 TimeoutException，又没在 finally 中调用 countDown()，主线程就会永远等不到归零——哪怕你写了超时，也只会在超时后返回 false，而不会唤醒其他等待线程。
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
正确写法示例：
executor.submit(() -> {
try {
Result r = callRemoteService();
results.add(r);
} catch (Exception e) {
errors.add(e);
} finally {
latch.countDown(); // 关键：无论如何都倒数
}
});
- 别在
catch里直接 return 或 throw 后漏掉countDown() - 别用
if (success) latch.countDown()这种条件式调用 - 如果子任务本身用了异步回调（如 CompletableFuture），确保回调里也包裹
finally或使用whenComplete统一兜底
不要把 CountDownLatch 当作结果收集器或错误传播通道
CountDownLatch 只负责“等数量”，不负责“传数据”或“抛异常”。想拿到各服务的响应或异常，必须额外设计共享结构：
- 用
ConcurrentHashMap<String, Object>存各服务结果，key 为服务名 - 用
AtomicInteger记录成功数，配合CountDownLatch判断是否“多数成功” - 用
CopyOnWriteArrayList<Throwable>收集所有异常，超时后统一处理 - 避免在
await()后直接取results.get(0)—— 如果第 0 个任务失败且没写入，会 NPE
超时退出后，真正的难点在于：要不要等剩余子任务自然结束？要不要主动中断它们？这取决于业务容忍度。强一致性场景（如资金操作）通常要等；高吞吐场景（如搜索聚合）可直接丢弃未完成结果。
