CountDownLatch是Java中用于线程同步的工具，通过计数器实现一个或多个线程等待其他线程完成任务后再执行。初始化时设定计数值，每个任务完成后调用countDown()使计数减一，等待线程调用await()阻塞直至计数归零。适用于并行任务协调、服务启动依赖、数据加载聚合等场景。与CyclicBarrier不同，CountDownLatch为一次性使用，不可重置，适合“等待所有任务完成”的模型。使用时需注意将countDown()放入finally块防止遗漏，避免因异常导致计数不归零；建议使用带超时的await()防止无限等待；正确设置初始计数值并与实际任务数匹配；妥善处理InterruptedException以保证中断状态不丢失。合理运用可提升并发程序的可靠性与效率。
在Java里，CountDownLatch是个挺有用的并发工具，说白了，它就是个计数器，主要用来协调多个线程的同步。它的核心思想是：让一个或多个线程等待，直到其他线程完成一系列操作后，这个计数器归零，等待的线程才能继续执行。这就像是你在等待所有朋友都到齐了，才能一起出发去旅行。
解决方案
使用CountDownLatch其实不复杂，主要就三个步骤：初始化、递减计数、等待。
首先，你需要创建一个CountDownLatch实例，构造函数里传入一个整数，这个数就是你需要等待完成的操作总数。
// 假设我们需要等待3个任务完成 CountDownLatch latch = new CountDownLatch(3);
接着，在每个任务完成时，调用countDown()方法。这个方法会将内部的计数器减一。
立即学习“Java免费学习笔记（深入）”；
// 在某个线程的任务逻辑中，任务完成时调用 latch.countDown();
最后，如果你有一个或多个线程需要等待这些任务完成，它们就调用await()方法。这个方法会阻塞当前线程，直到CountDownLatch的计数器归零。
// 主线程或者某个协调线程，需要等待所有任务完成
try {
latch.await(); // 阻塞，直到计数器为0
System.out.println("所有任务都完成了，可以继续执行主逻辑了。");
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // 重新设置中断状态
System.err.println("等待过程中被中断了：" + e.getMessage());
}一个简单的例子，我们模拟一个主线程等待三个子线程完成各自的工作：
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class CountDownLatchDemo {
public static void main(String[] args) {
// 假设有3个子任务需要完成
CountDownLatch latch = new CountDownLatch(3);
ExecutorService executor = Executors.newFixedThreadPool(3);
System.out.println("主线程：开始等待所有子任务完成...");
// 提交三个子任务
for (int i = 0; i < 3; i++) {
final int taskId = i + 1;
executor.submit(() -> {
try {
System.out.println("子任务 " + taskId + "：正在执行...");
TimeUnit.SECONDS.sleep((long) (Math.random() * 3) + 1); // 模拟耗时操作
System.out.println("子任务 " + taskId + "：执行完毕。");
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
System.err.println("子任务 " + taskId + " 被中断。");
} finally {
latch.countDown(); // 任务完成，计数器减一
System.out.println("CountDown！当前剩余任务数：" + latch.getCount());
}
});
}
try {
latch.await(); // 主线程阻塞，等待所有子任务完成
System.out.println("主线程：所有子任务都完成了，继续执行后续操作。");
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
System.err.println("主线程等待过程中被中断。");
} finally {
executor.shutdown(); // 关闭线程池
try {
if (!executor.awaitTermination(5, TimeUnit.SECONDS)) {
System.err.println("线程池未在规定时间内关闭。");
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
}
}运行这段代码，你会看到主线程会一直等到所有子任务都打印出“执行完毕”并调用countDown()之后，才会继续执行它自己的“所有子任务都完成了”这行代码。
CountDownLatch与CyclicBarrier有什么区别？我该如何选择？
这是一个经典问题，很多初学者都会纠结。说白了，CountDownLatch和CyclicBarrier都是并发同步工具，但它们的设计哲学和使用场景有所不同。
CountDownLatch更像是一个“一次性”的门闩。一旦计数器归零，它就失效了，不能重用。它通常用于一个或多个线程等待其他一组线程完成工作。它的计数器是向下递减的，从N减到0。想象一下，你发号施令，让大家开始干活，然后你等在终点线，等所有人都冲过终点，你才宣布结束。它是一个“等待所有人完成”的模型。
而CyclicBarrier则是一个“循环的栅栏”，顾名思义，它是可以重复使用的。它允许一组线程在某个点相互等待，直到所有线程都到达这个“栅栏点”，然后所有线程可以一起越过栅栏，继续执行，并且这个栅栏还可以重置，供下一轮使用。它的计数器是向上递增的，从0加到N，然后重置。这更像是一群人在玩接力赛，每跑完一棒，大家都要在交接点等齐了，才能开始下一棒。它是一个“所有人都到达某个点，然后一起继续”的模型。
如何选择？
-
如果你需要一个线程（或多个线程）等待其他一组线程完成，并且这个等待过程只发生一次，那么
CountDownLatch是你的首选。比如，启动一个服务时，需要等待多个模块初始化完成；或者一个大数据任务，需要等待所有子任务数据处理完毕。 -
如果你需要一组线程相互等待，达到一个共同点后一起继续执行，并且这个过程可能重复发生（比如迭代计算、游戏回合），那么
CyclicBarrier更合适。它还可以在所有线程都到达栅栏点时执行一个预定义的操作（通过构造函数传入一个Runnable）。
我个人觉得，CountDownLatch的语义更直接，就是“数着还有多少活没干完”，而CyclicBarrier则强调“大家一起走到某个地方”。理解了这点，选择起来就容易多了。
CountDownLatch在实际项目中有哪些典型应用场景？
在实际开发中，CountDownLatch的应用场景还是挺多的，尤其是涉及到并发和资源协调的地方。
-
并行任务的启动与协调： 这是最常见的场景。比如，你需要处理一个大任务，可以将其拆分成多个子任务，然后用线程池并行执行这些子任务。主线程用
CountDownLatch等待所有子任务完成，然后对结果进行汇总或进行后续处理。这能显著提高处理效率。// 假设有10个数据块需要并行处理 CountDownLatch dataProcessLatch = new CountDownLatch(10); ExecutorService dataProcessor = Executors.newFixedThreadPool(5); for (int i = 0; i < 10; i++) { final int blockId = i; dataProcessor.submit(() -> { try { // 处理数据块 blockId System.out.println("处理数据块：" + blockId); TimeUnit.MILLISECONDS.sleep(new Random().nextInt(500)); } catch (InterruptedException e) { Thread.currentThread().interrupt(); } finally { dataProcessLatch.countDown(); } }); } dataProcessLatch.await(); // 等待所有数据块处理完成 System.out.println("所有数据块处理完毕，开始汇总结果。"); 服务启动依赖： 在一些复杂的微服务或模块化应用中，一个核心服务可能需要等待其他多个依赖服务或组件初始化完成后才能正式对外提供服务。这时候，
CountDownLatch就能派上用场。每个依赖服务初始化完成后就countDown()，主启动线程await()，确保所有前置条件都满足。性能测试： 在进行并发性能测试时，你可能希望所有测试线程在同一个时间点开始执行，以确保测试的公平性。你可以用一个
CountDownLatch让所有测试线程等待，直到主线程发出“开始”信号（通过countDown()一次性释放所有等待线程）。不过，这种场景下，CyclicBarrier可能更合适，因为它能重复使用，适合多轮测试。但如果只是单次并发启动，CountDownLatch也勉强能用。数据加载与聚合： 比如，你需要从多个数据源并行加载数据，然后将它们聚合成一个完整的数据集。每个数据源加载完成后就
countDown()，主线程等待所有数据加载完毕后再进行聚合操作。
这些场景都体现了CountDownLatch“等待所有前置任务完成”的核心能力。它简单、高效，是Java并发工具箱里一个非常实用的组件。
使用CountDownLatch时，有哪些需要注意的线程安全问题和潜在的死锁风险？
虽然CountDownLatch本身设计得很健壮，但使用不当还是可能带来一些问题。
-
忘记调用
countDown()： 这是最常见的错误。如果某个子任务在执行过程中抛出异常，或者因为逻辑问题没有执行到countDown()方法，那么CountDownLatch的计数器就不会归零。结果就是，所有调用await()的线程会永远阻塞在那里，造成“活锁”或者“死锁”（严格来说是活锁，因为线程还在运行，只是永远等不到结果），这在生产环境中是灾难性的。 解决办法： 务必将countDown()放在finally块中，确保任务无论成功失败，都能递减计数。try { // 任务逻辑 } catch (Exception e) { // 异常处理 } finally { latch.countDown(); // 确保在finally块中调用 } InterruptedException的处理：await()方法会抛出InterruptedException。这意味着等待的线程可能会被其他线程中断。在捕获这个异常时，通常需要重新设置当前线程的中断状态 (Thread.currentThread().interrupt();)，并妥善处理业务逻辑，比如是否需要终止当前任务或回滚操作。忽视这个异常可能会导致中断信号丢失，影响程序的响应性。计数器设置不当： 如果你初始化的计数器值比实际调用
countDown()的次数少，那么await()可能会过早地解除阻塞。反之，如果计数器值比实际调用次数多，那么await()会永远阻塞。所以，确保CountDownLatch的初始值与需要等待的任务数量严格匹配，这一点非常关键。-
没有超时机制的
await()：latch.await()是一个无限期的等待。如果在某些极端情况下，子任务真的出了问题，导致countDown()没有被调用，那么你的主线程就会永远等下去。为了避免这种情况，最好使用带超时参数的await()方法：latch.await(timeout, unit)。这样，即使子任务卡住了，主线程也能在一定时间后解除阻塞，并进行错误处理或重试。boolean allTasksCompleted = latch.await(10, TimeUnit.SECONDS); if (!allTasksCompleted) { System.err.println("警告：部分任务在规定时间内未能完成！"); // 进一步处理，比如记录日志、发送告警、尝试终止未完成任务等 } 不恰当的异常处理： 在子任务中，如果发生未捕获的异常，可能会导致线程终止，但
countDown()没有被执行。这同样会导致主线程无限期等待。在使用线程池时，可以考虑为ExecutorService设置UncaughtExceptionHandler，或者在Runnable或Callable的run()或call()方法内部进行全面的异常捕获。
总的来说，CountDownLatch是一个相对安全的工具，它本身不会引入死锁，因为它只是一个单向的计数器。但它的“等待”机制如果配合不当，很容易造成线程无限期阻塞，这跟死锁的效果差不多，需要特别小心。多用finally，多考虑超时，是避免这些问题的关键。
