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

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()，否则主线程的判断就会出问题：

• 最稳妥的做法是放 finally 块里，这样不管异常还是 return 都能保证计数被减掉
• 别让主线程去替它调用，也别在核心逻辑还没跑完之前就提前 countDown
• 多个子任务可以跨不同的线程来调用（比如线程池任务、CompletableFuture 回调、事件监听器），完全不需要加锁同步——线程安全由 AQS 保证
• countDown() 本身就是线程安全的，多个线程并发减计数不会乱

与 join() 的本质区别

CountDownLatch 的阻塞逻辑跟 Thread.join() 完全是两码事：

• join() 必须绑定到某个具体的 Thread 对象上，你得持有那个线程的引用才能调用它，线程池提交的 Runnable 根本没法用
• CountDownLatch 盯着的是“事件发生的次数”，而不是线程的生老病死；哪怕子线程已经跑完了，只要忘记调 countDown，主线程照样卡住
• 它支持任意执行单元（Callable、Runnable、回调函数），解耦更彻底，更适合现代异步编程的玩法
• 计数归零后就废了，不能重复用；要循环等待的场景，得去请 CyclicBarrier 出场