CountDownLatch 采用基于 AQS 的 volatile + CAS 原子倒计时机制，无锁、低开销、纳秒级响应；仅在 state 归零时批量唤醒等待线程，避免惊群效应；不可重用性保障性能，超时与中断支持不增加常态开销。

CountDownLatch 的计数器设计直接决定了它的同步性能表现——它不是靠轮询或锁竞争实现等待，而是用原子、无锁、一次性的倒计时机制完成线程协调，因此开销极低、响应迅速。

计数器基于 AQS 的 volatile + CAS 实现

内部计数器就是 AQS 的 state 字段，被 volatile 修饰，保证多线程下的可见性；所有更新（countDown()）都通过 CAS 原子操作完成，不依赖 synchronized 或显式锁。这意味着：

• 没有锁膨胀、没有上下文切换开销
• 多个线程并发调用 countDown() 不会互相阻塞
• 计数递减和归零判断是 CPU 级原子指令，延迟在纳秒级

唤醒机制是批量且惰性的

只有当最后一次 countDown() 使 state 变为 0 时，AQS 才遍历同步队列，对所有等待节点统一执行 LockSupport.unpark()。这种设计带来明显优势：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 避免“惊群效应”：不是每次 countDown() 都唤醒，只在真正就绪时批量唤醒
• 唤醒过程不抢占 CPU：无需忙等待，线程处于 park 状态，由 JVM 底层调度唤醒
• 等待线程数量不影响单次 await() 进入阻塞的开销，只影响最终唤醒的遍历成本（通常可忽略）

不可重用性反而是性能保障

CountDownLatch 计数器归零后不可重置，表面看是限制，实则是性能取舍：

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

• 省去了重置状态所需的额外同步逻辑（比如清空队列、重置 state、重新校验等）
• 避免了重用场景下可能引入的竞态条件与内存屏障开销
• 若需循环等待，CyclicBarrier 已专为此优化，不必让 CountDownLatch 承担双重职责

超时与中断支持不增加常态开销

await(long, TimeUnit) 和中断响应能力是可选增强，底层仍复用同一套 AQS 逻辑：

• 未设超时时，纯阻塞等待，零额外判断
• 设超时时，仅在 park 前注册定时任务，唤醒路径不变
• 中断处理发生在唤醒过程中，不干扰正常计数流程