CountDownLatch 通过 AQS 实现计数器驱动的线程阻塞与唤醒，主线程调用 await() 阻塞，子线程调用 countDown() 递减计数，归零后唤醒所有等待线程；它不依赖线程引用，支持线程池和异步场景，不可重用。
CountDownLatch 通过一个内部递减计数器，让主线程在调用 await() 时进入阻塞状态，直到所有子任务调用 countDown() 将计数器减至 0，主线程才被唤醒继续执行。它不依赖线程对象本身，也不要求主线程与子线程有直接引用关系，适用于线程池、异步回调等松耦合场景。
计数器驱动的阻塞逻辑
CountDownLatch 的阻塞不是靠轮询或忙等待，而是基于 AQS（AbstractQueuedSynchronizer）的共享锁机制实现：
- 构造时传入的 count 值被设为 AQS 的 state
- await() 调用会尝试获取共享锁；若 state ≠ 0，则当前线程被封装为节点加入同步队列并挂起（park）
- countDown() 使用 CAS 尝试将 state 减 1；一旦 state 变为 0，就唤醒队列中所有等待线程
- 唤醒后，后续任何线程再调用 await() 都会立即返回，因为 state 已不可变
主线程如何安全等待
主线程只需在启动全部子任务后调用 await()，但必须注意超时与中断处理：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 避免无超时的 await()：网络延迟、死循环或异常跳过 countDown 都可能导致永久阻塞
- 推荐使用 await(long, TimeUnit)，返回 boolean 表示是否成功等到归零
- 捕获 InterruptedException 并合理处理（如恢复中断状态、清理资源）
- 不要在 await 前做耗时操作，否则会拉长整体等待窗口
子线程如何确保计数准确
每个子任务必须且仅调用一次 countDown()，否则会影响主线程判断：
立即学习“Java免费学习笔记（深入）”；
- 放在 finally 块中是最稳妥的做法，确保异常或 return 都能触发计数
- 不能由主线程代为调用，也不能在未完成核心逻辑前提前调用
- 多个子任务可跨不同线程（如线程池任务、CompletableFuture 回调、事件监听器）调用，无需同步
- countDown() 是线程安全的，多线程并发调用不会导致计数错乱
与 join() 的本质区别
CountDownLatch 的阻塞逻辑与 Thread.join() 完全不同：
- join() 是对特定 Thread 对象的阻塞，需持有线程引用，无法用于线程池提交的 Runnable
- CountDownLatch 关注的是“事件数量”，而非线程生命周期；即使子线程已结束但忘记 countDown，主线程仍会卡住
- 它支持任意执行单元（Callable、Runnable、回调函数），解耦更彻底，更适合现代异步编程模型
- 计数归零后不可重用；如需循环等待，应选用 CyclicBarrier
