当前位置：首页 > news >正文

CountDownLatch、CyclicBarrier、Semaphore 的区别？

news 2026/6/16 16:15:10

三者都是 JDK 并发包 java.util.concurrent 中用于线程协作的工具类，但设计目标和行为模式有本质区别。

工具类	核心模型/比喻	关键特性	主要用途
`CountDownLatch`	一次性门闩/倒计时器	1. 一次性：计数器归零后无法重置。 2. 被动等待：一个或多个线程等待其他一组线程完成任务。	主线程等待多个前置服务初始化完成；模拟并发测试的起跑线。
`CyclicBarrier`	可循环使用的栅栏	1. 可循环使用：计数器归零后会自动重置，可重复使用。 2. 主动协同：一组线程相互等待，全部到达屏障点后，可执行一个预定义任务，然后一起继续执行。	分阶段任务，如多线程数据计算，需合并每阶段结果；多线程分批处理任务。
`Semaphore`	信号量/资源访问许可	1. 控制并发访问数：基于许可（permits）的模型。 2. 可增减许可：支持释放许可增加资源数。 3. 常用于资源池或流量控制。	数据库连接池限流；限流场景（如最多 N 个线程同时访问某 API）。

简单来说：CountDownLatch 是 “我等你”（一等多），CyclicBarrier 是 “我们到齐了一起走”（多等多，可循环），Semaphore 是 “只有 N 个名额，先到先得”（控制流量）。

深度解析

原理/机制

CountDownLatch：内部维护一个计数器 count。初始化时设定一个正整数。线程调用 countDown() 方法会将计数器减 1。调用 await() 的线程会被阻塞，直到计数器变为 0。
CyclicBarrier：内部维护一个计数器 parties 和一个 Runnable 屏障动作（可选）。每个线程调用 await() 表示它已到达屏障，此时计数器减 1。当计数器为 0 时，所有线程被释放，屏障动作（如果存在）会由一个最后到达屏障的线程执行，然后计数器重置为 parties，可开始下一轮循环。
Semaphore：内部维护一组许可（permits）。线程调用 acquire() 尝试获取一个许可，如果无可用许可则阻塞；调用 release() 释放一个许可。可以创建公平或非公平的信号量。

重要底层共性：它们都依赖于强大的 AQS 框架来实现底层的线程排队、阻塞与唤醒机制。

代码示例

import java.util.concurrent.*;// 1. CountDownLatch 示例：主线程等待3个前置任务完成
public class CountDownLatchDemo {public static void main(String[] args) throws InterruptedException {CountDownLatch latch = new CountDownLatch(3);ExecutorService executor = Executors.newFixedThreadPool(3);for (int i = 1; i <= 3; i++) {final int taskId = i;executor.submit(() -> {try {// 模拟任务执行耗时Thread.sleep((long) (Math.random() * 1000));System.out.println("Task " + taskId + " completed.");} catch (InterruptedException e) {Thread.currentThread().interrupt();} finally {latch.countDown(); // 任务完成，计数器减1}});}System.out.println("Main thread waiting for all tasks...");latch.await(); // 主线程在此阻塞，直到计数器为0System.out.println("All tasks completed. Main thread proceeds.");executor.shutdown();}
}// 2. CyclicBarrier 示例：4个运动员（线程）在起跑线（屏障）集合，然后同时开跑
public class CyclicBarrierDemo {public static void main(String[] args) {int runnerCount = 4;// 屏障动作：当所有运动员都准备好后，由最后一个调用 await() 的线程执行CyclicBarrier barrier = new CyclicBarrier(runnerCount,() -> System.out.println("All runners ready! Go!"));ExecutorService executor = Executors.newFixedThreadPool(runnerCount);for (int i = 1; i <= runnerCount; i++) {final int runnerId = i;executor.submit(() -> {try {System.out.println("Runner " + runnerId + " is preparing...");Thread.sleep((long) (Math.random() * 1000));System.out.println("Runner " + runnerId + " is ready.");barrier.await(); // 运动员到达起跑线等待// 所有运动员都到达后，同时开始跑步System.out.println("Runner " + runnerId + " starts running!");} catch (Exception e) {e.printStackTrace();}});}executor.shutdown();}
}

最佳实践与常见误区

CountDownLatch：
- 最佳实践：确保 countDown() 在 finally 块中调用，以防任务异常导致计数器无法归零，进而造成主线程永久等待。
CyclicBarrier：
- 常见误区：如果线程池的核心线程数小于屏障数（parties），且没有足够的空闲线程来处理被释放的线程，可能会导致死锁。例如，一个 parties=5 的 CyclicBarrier 与一个只有 4 个线程的线程池一起使用，就会出现这种问题。
- 重要特性：它的 reset() 方法可以强制重置屏障，但会唤醒所有等待的线程并抛出 BrokenBarrierException。屏障在破损（如线程被中断）后，需要重置或新建才能继续使用。
Semaphore：
- 最佳实践：同样，acquire() 的调用应谨慎，或使用 tryAcquire() 带超时的方法，避免永久阻塞。release() 也建议放在 finally 块中。
- 公平性：初始化时可指定是否为公平模式。在竞争激烈且要求严格 FIFO 的场景下，公平模式可以避免线程饥饿。