详解 Java 中 CountDownLatch 对主线程的任务阻塞机制

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()，但必须注意超时与中断处理：

• 避免无超时的 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