countdownlatch 是一次性线程同步工具，用于等待n个线程完成任务：主线程调用await()阻塞，工作线程调用countdown()递减计数，归零后继续执行；不可重用，需配合try-finally保证countdown()执行，避免死锁。
CountDownLatch 是 Java 并发包中用于线程间同步的常用工具，核心作用是“等待一组操作完成”，适合“一个或多个线程等待其他 N 个线程执行完毕后再继续”的协作场景。它不可重用，计数器归零后无法重置，设计上强调一次性协调。
明确角色分工：主线程等待，工作线程倒计时
使用 CountDownLatch 的关键在于清晰划分等待方（如主线程）和执行方（如多个子线程）。构造时传入初始计数值（即需等待的线程数），每个工作线程完成任务后调用 countDown()；等待方调用 await() 阻塞直到计数归零。
- 不要在工作线程中重复调用 countDown() 多次（除非逻辑确实需要多次贡献完成信号）
- await() 可带超时参数，避免无限等待；返回 false 表示超时，需主动处理失败路径
- 主线程调用 await() 前，必须确保所有工作线程已启动（否则可能提前结束等待）
配合 ExecutorService 管理线程生命周期
实际项目中，通常搭配线程池使用。提交任务时，每个 Runnable/Callable 内部完成业务逻辑后调用 countDown()；主线程在 submit 后立即 await，实现“发令—执行—汇合”流程。
- 线程池大小不一定要等于 CountDownLatch 初始值，但需保证至少有 N 个任务被提交并执行
- 若任务抛出异常，countDown() 可能未被执行，导致 await 永久阻塞——应在 catch 块中补调 countDown()
- 无需手动 shutdown 线程池来配合 CountDownLatch，两者职责正交：后者管同步，前者管线程复用
避免与 CyclicBarrier 混淆：单次 vs 循环
CountDownLatch 是“一次性门闩”，适用于启动阶段的汇聚（如服务初始化等待多个组件就绪）；而 CyclicBarrier 支持重复使用，适合多阶段协同计算（如迭代算法每轮等待全部线程到达栅栏）。选型时看是否需要复位能力。
- 若需“等待全部线程到达后一起继续，并重复该过程”，应选 CyclicBarrier
- 若只是“等所有前置任务做完，再做后续动作”，CountDownLatch 更轻量、语义更直接
- CountDownLatch 不感知参与线程的身份，也不提供到达时的回调；如需此类能力，可考虑 Phaser 或自定义封装
典型错误与健壮性建议
常见误用包括：在未启动线程前就 await、忽略中断响应、漏掉 countDown 导致死锁。提升健壮性的做法有：
- 将 CountDownLatch 声明为 final，避免意外重新赋值
- 在工作线程中用 try-finally 包裹业务逻辑，确保 countDown() 最终执行
- 主线程 await 时检查 Thread.interrupted()，及时响应中断并清理资源
- 日志中记录剩余计数（getCount()），便于排查卡点
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
