CountDownLatch.await()永久阻塞主因是子任务未执行countDown()，须将countDown()置于finally块、使用带超时的await()、确保任务实际调度，并添加监控与日志。
主线程在 CountDownLatch.await() 处永久阻塞，最常见原因就是某个子任务本该执行 countDown() 却没执行——不是 CountDownLatch 有缺陷，而是调用逻辑不可靠。关键在于让“倒计时”成为任务退出的必然动作，而非可选分支。
所有 countDown() 必须放在 finally 块里
网络 IO、数据库查询、HTTP 调用等极易因超时、连接失败、异常中断而提前退出 try 块。一旦 countDown() 写在 try 或 catch 中，就可能被跳过。
- 错误写法：只在成功路径或特定异常分支里调用，其余路径静默遗漏
- 正确写法：无论是否抛异常、是否超时、是否 return，只要子任务逻辑“退出”，就必须减一次
- 示例：务必把
latch.countDown()放进finally，并在日志中打印剩余计数便于排查
await() 永远不许用无参版本
无参 await() 一旦漏减，就会无限等待，且无任何唤醒机制。这不是容错，是埋雷。
- 必须使用带超时的
await(long timeout, TimeUnit unit) - 超时值参考业务 SLA：例如主链路要求 2 秒返回，IO 最长容忍 1.5 秒，则设为 3 秒
- 超时返回
false后，立即记录告警、降级（如返回缓存/默认值）、打印latch.getCount()确认卡在哪一环
确认子任务真被调度执行了
有时候不是逻辑漏了 countDown()，而是任务压根没跑起来——线程池满了、被拒绝策略丢弃、回调没注册成功。
立即学习“Java免费学习笔记（深入）”；
- 检查线程池状态：
executor.getActiveCount()、executor.getQueue().size() - 避免无界队列，改用有界队列 +
CallerRunsPolicy：队列满时由主线程自己执行任务，至少保证倒计时发出 - 对
CompletableFuture或事件回调，确认thenAccept/subscribe等注册成功，且上游确实完成
加一层轻量监控和兜底
线上问题发现越晚，影响越大。主动暴露比被动等待更可靠。
- 在关键路径启动守护线程，定期检查
latch.getCount()是否长期非零，超时即告警 - 在每次
countDown()前打结构化日志：任务 ID、线程名、堆栈片段，方便快速定位哪类任务总不触发 - CI 阶段加入静态检查规则，强制所有
new CountDownLatch对应的countDown()出现在finally块内
