你好，我是老码农！今天我们来聊聊 Java 并发编程中一个非常实用的工具——CyclicBarrier。 它就像一个“栅栏”，可以协调多个线程，让它们在某个时间点同步，一起“跨越”这道栅栏，继续执行后续任务。这在很多场景下都非常有用，比如模拟团队协作、数据汇总等。
1. CyclicBarrier 是什么？
CyclicBarrier，直译过来就是“循环栅栏”。 顾名思义，它允许一组线程在到达一个共同的“屏障点”（barrier point）时互相等待，直到所有线程都到达该屏障点后，屏障才会“打开”，所有线程才能继续执行。 并且，这个屏障是可以循环使用的，一旦线程都通过了栅栏，它可以被重置，供后续线程继续使用。
CyclicBarrier 主要有以下几个特点：
- 循环性 (Cyclic)：
CyclicBarrier可以被重复使用。 一旦线程通过栅栏，它会自动重置，可以供后续线程继续使用。 - 屏障点 (Barrier Point)： 线程会在一个共同的屏障点等待，直到所有线程都到达该点。
- 计数器 (Count)：
CyclicBarrier内部维护一个计数器，用于记录到达屏障点的线程数量。 当计数器达到预设值时，屏障打开。 - 可执行任务 (Runnable)： 在所有线程到达屏障点后，
CyclicBarrier允许执行一个可选的Runnable任务，这个任务通常用于汇总结果或者进行后续操作。
CyclicBarrier 的构造方法：
public CyclicBarrier(int parties, Runnable barrierAction)
public CyclicBarrier(int parties)
parties: 指定需要同步的线程数量，也就是栅栏允许通过的线程数量。barrierAction: 一个Runnable任务，在所有线程都到达栅栏时执行。 可选参数。
CyclicBarrier 的核心方法：
await(): 线程调用此方法，表示线程已经到达栅栏，开始等待其他线程。 该方法会阻塞当前线程，直到以下情况发生：- 所有线程都到达栅栏。
- 当前线程被中断。
CyclicBarrier被重置。- 超时（如果使用了
await(long timeout, TimeUnit unit)方法）。
getNumberWaiting(): 返回当前在栅栏处等待的线程数量。isBroken(): 判断栅栏是否处于损坏状态。 如果有线程被中断，或者发生超时，栅栏会进入损坏状态。reset(): 重置栅栏，将其恢复到初始状态。 所有在栅栏处等待的线程都会抛出BrokenBarrierException异常。
2. CyclicBarrier 的应用场景
CyclicBarrier 适用于需要多个线程协同工作，并在某个时刻同步的场景。 下面列举几个常见的应用场景：
- 团队协作: 模拟一个团队完成任务，每个线程代表一个团队成员，当所有成员都完成各自的任务后，团队才能进行下一步操作。
- 数据汇总: 将多个线程计算的结果进行汇总，所有线程计算完成后，再进行汇总操作。
- 并行计算: 将一个大任务拆分成多个小任务，分配给不同的线程并行处理，所有线程处理完成后，再合并结果。
- 游戏开发: 在游戏开发中，可以使用
CyclicBarrier来同步游戏中的不同对象的状态，例如，在每个游戏帧开始前，所有对象的状态都需要同步。 - 测试框架: 在自动化测试框架中，可以使用
CyclicBarrier来确保在执行测试用例之前，所有必要的准备工作都已完成。
3. 模拟团队协作：实战 CyclicBarrier
我们通过一个模拟团队协作的例子，来深入理解 CyclicBarrier 的使用。 假设一个团队要完成一个项目，项目分为多个阶段，每个阶段由不同的团队成员负责。所有成员完成当前阶段的任务后，才能进入下一个阶段。
import java.util.concurrent.BrokenBarrierException;
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
public class TeamCollaboration {
// 团队成员数量
private static final int TEAM_SIZE = 3;
// 模拟任务阶段数量
private static final int STAGES = 3;
public static void main(String[] args) {
// 创建 CyclicBarrier，指定需要同步的线程数量和栅栏动作
CyclicBarrier barrier = new CyclicBarrier(TEAM_SIZE, () -> {
System.out.println("\n--- 所有成员完成当前阶段任务，团队准备进入下一阶段 ---\n");
});
// 创建线程池
ExecutorService executor = Executors.newFixedThreadPool(TEAM_SIZE);
// 创建团队成员
for (int i = 0; i < TEAM_SIZE; i++) {
final int memberId = i + 1;
executor.submit(() -> {
try {
for (int stage = 1; stage <= STAGES; stage++) {
System.out.println("成员 " + memberId + " 正在完成第 " + stage + " 阶段的任务...");
// 模拟任务耗时
Thread.sleep((long) (Math.random() * 1000));
System.out.println("成员 " + memberId + " 完成第 " + stage + " 阶段的任务，等待其他成员...");
// 线程到达栅栏，等待其他线程
barrier.await();
}
System.out.println("成员 " + memberId + " 完成所有阶段的任务，退出工作！");
} catch (InterruptedException | BrokenBarrierException e) {
Thread.currentThread().interrupt(); // 重新设置中断状态
System.err.println("成员 " + memberId + " 在协作过程中发生异常: " + e.getMessage());
} catch (Exception e) {
System.err.println("成员 " + memberId + " 发生未知异常: " + e.getMessage());
}
});
}
// 关闭线程池
executor.shutdown();
}
}
代码解释：
- 创建
CyclicBarrier: 我们创建了一个CyclicBarrier对象，TEAM_SIZE表示团队成员的数量，也是需要同步的线程数量。 第二个参数是一个Runnable类型的匿名内部类，作为栅栏动作，在所有线程到达栅栏时执行。 这里我们简单地打印一条消息，表示团队准备进入下一阶段。 - 创建线程池: 使用
ExecutorService创建一个固定大小的线程池，线程池的大小与团队成员数量相同。 - 创建团队成员: 循环创建多个线程，每个线程代表一个团队成员。 线程的
run()方法模拟了成员完成任务的过程：- 模拟任务： 每个线程模拟完成多个阶段的任务。
- 等待其他成员： 线程调用
barrier.await()方法，表示线程已经完成当前阶段的任务，并开始等待其他成员。 - 栅栏动作： 当所有线程都调用了
await()方法时，栅栏动作被执行，然后所有线程继续执行下一阶段的任务。
- 关闭线程池: 在所有任务完成后，关闭线程池。
运行结果示例：
成员 1 正在完成第 1 阶段的任务...
成员 2 正在完成第 1 阶段的任务...
成员 3 正在完成第 1 阶段的任务...
成员 1 完成第 1 阶段的任务，等待其他成员...
成员 2 完成第 1 阶段的任务，等待其他成员...
成员 3 完成第 1 阶段的任务，等待其他成员...
--- 所有成员完成当前阶段任务，团队准备进入下一阶段 ---
成员 1 正在完成第 2 阶段的任务...
成员 2 正在完成第 2 阶段的任务...
成员 3 正在完成第 2 阶段的任务...
成员 1 完成第 2 阶段的任务，等待其他成员...
成员 2 完成第 2 阶段的任务，等待其他成员...
成员 3 完成第 2 阶段的任务，等待其他成员...
--- 所有成员完成当前阶段任务，团队准备进入下一阶段 ---
成员 1 正在完成第 3 阶段的任务...
成员 2 正在完成第 3 阶段的任务...
成员 3 正在完成第 3 阶段的任务...
成员 1 完成第 3 阶段的任务，等待其他成员...
成员 2 完成第 3 阶段的任务，等待其他成员...
成员 3 完成第 3 阶段的任务，等待其他成员...
--- 所有成员完成当前阶段任务，团队准备进入下一阶段 ---
成员 1 完成所有阶段的任务，退出工作！
成员 2 完成所有阶段的任务，退出工作！
成员 3 完成所有阶段的任务，退出工作！
从输出结果可以看出，每个成员都按顺序完成了每个阶段的任务，并且在每个阶段结束时，所有成员都会在栅栏处同步，等待其他成员完成后，再一起进入下一阶段。
4. CyclicBarrier 的进阶应用：处理异常和中断
在实际应用中，我们需要考虑线程可能出现异常或者被中断的情况。 CyclicBarrier 提供了处理这些情况的机制。
4.1 异常处理
如果在线程执行过程中发生异常，会导致 CyclicBarrier 进入“损坏”状态，后续的 await() 调用会抛出 BrokenBarrierException 异常。 我们可以在 try-catch 块中捕获这个异常，并进行相应的处理。
// ...
try {
barrier.await();
} catch (BrokenBarrierException e) {
// 栅栏损坏，处理异常
System.err.println("栅栏损坏，原因: " + e.getMessage());
// 可以尝试重置栅栏，或者采取其他补救措施
// barrier.reset();
} catch (InterruptedException e) {
// 线程被中断，处理中断异常
Thread.currentThread().interrupt(); // 重新设置中断状态
System.err.println("线程被中断: " + e.getMessage());
}
// ...
在上面的代码中，我们捕获了 BrokenBarrierException 和 InterruptedException 异常，并打印错误信息。 BrokenBarrierException 表明栅栏已经损坏，我们需要采取相应的措施，例如重置栅栏或者通知其他线程。 InterruptedException 表明线程被中断，我们需要重新设置中断状态，以便后续代码可以正确处理中断。
4.2 中断处理
线程在 await() 方法中阻塞时，如果被中断，会抛出 InterruptedException 异常。 我们需要在 catch 块中处理这个异常，并根据需要进行相应的处理。
// ...
try {
barrier.await();
} catch (InterruptedException e) {
// 线程被中断，处理中断异常
Thread.currentThread().interrupt(); // 重新设置中断状态
System.err.println("线程被中断: " + e.getMessage());
// 可以采取其他补救措施，例如退出线程，或者通知其他线程
// ...
}
// ...
在处理 InterruptedException 异常时，我们首先需要调用 Thread.currentThread().interrupt() 重新设置中断状态。 这是因为 InterruptedException 异常会被捕获，但是中断状态会被清除。 重新设置中断状态可以确保后续代码可以正确地处理中断。 然后，我们可以根据需要采取其他补救措施，例如退出线程或者通知其他线程。
4.3 超时处理
CyclicBarrier 还提供了带有超时时间的 await() 方法： await(long timeout, TimeUnit unit)。 如果线程在指定时间内没有到达栅栏，会抛出 TimeoutException 异常。 这在某些场景下非常有用，例如，避免线程无限期地等待。
import java.util.concurrent.TimeoutException;
import java.util.concurrent.TimeUnit;
// ...
try {
boolean reached = barrier.await(5, TimeUnit.SECONDS);
if (!reached) {
System.out.println("线程超时，未能到达栅栏");
}
} catch (TimeoutException e) {
// 超时异常处理
System.err.println("线程超时: " + e.getMessage());
// 可以采取其他补救措施
// ...
}
// ...
在上面的代码中，我们设置了 5 秒的超时时间。 如果线程在 5 秒内没有到达栅栏，会抛出 TimeoutException 异常。 我们可以捕获这个异常，并进行相应的处理。
5. CyclicBarrier 与 CountDownLatch 的区别
CyclicBarrier 和 CountDownLatch 都是 Java 并发编程中用于线程同步的工具，但它们的应用场景和使用方式有所不同。
| 特性 | CyclicBarrier | CountDownLatch |
|---|---|---|
| 功能 | 线程在栅栏处等待，直到所有线程都到达栅栏。 | 一个或多个线程等待其他线程完成操作。 |
| 可重用性 | 可以重复使用。 栅栏打开后，可以被重置。 | 只能使用一次。 计数器变为 0 后，无法重置。 |
| 计数方式 | 线程数量 | 计数器，可以递减到 0 |
| 栅栏动作 | 所有线程到达栅栏后，可以执行一个可选的 Runnable 任务。 | 没有内置的栅栏动作。 |
| 应用场景 | 团队协作、数据汇总、并行计算等。 | 等待其他线程完成初始化、等待所有任务完成等。 |
简单来说：
CountDownLatch更像是“倒计时门栓”。 一个线程（或者一组线程）等待其他线程完成某项任务，就像倒计时一样，当计数器减为 0 时，门栓打开，等待的线程就可以继续执行。CountDownLatch只能使用一次。CyclicBarrier更像是“循环栅栏”。 一组线程在栅栏处等待，直到所有线程都到达栅栏，然后所有线程一起“跨越”栅栏。CyclicBarrier可以重复使用，可以循环利用。
选择哪个工具，取决于你的实际需求。
6. CyclicBarrier 的性能考虑
CyclicBarrier 的性能通常是比较好的，但是在使用时，也需要注意一些问题，以避免潜在的性能瓶颈：
- 线程数量:
CyclicBarrier的性能与线程数量有关。 当需要同步的线程数量非常多时，CyclicBarrier的开销可能会增加。 在这种情况下，可以考虑使用其他并发工具，或者优化代码结构，减少线程数量。 - 栅栏动作: 栅栏动作的执行时间会影响所有线程的等待时间。 如果栅栏动作比较耗时，会导致线程在栅栏处等待的时间变长。 因此，应尽量避免在栅栏动作中执行耗时操作，或者将耗时操作异步化。
- 异常处理: 异常处理会影响程序的性能。 在处理
BrokenBarrierException和InterruptedException异常时，需要小心处理，避免出现死锁或者性能问题。 - 资源竞争:
CyclicBarrier内部可能存在资源竞争，例如计数器的更新。 虽然 Java 的并发库已经做了优化，但是仍然可能存在一定的开销。 在设计多线程程序时，应尽量减少资源竞争，提高程序的整体性能。
7. 总结
CyclicBarrier 是一个强大的并发工具，它提供了一种优雅的方式来协调多个线程的同步。 它可以用于模拟团队协作、数据汇总、并行计算等场景。 通过本文的讲解，相信你已经对 CyclicBarrier 有了深入的理解，并掌握了它的使用方法。 在实际开发中，根据具体的业务场景，选择合适的并发工具，可以有效地提高程序的性能和可维护性。 希望这篇文章能帮助你更好地掌握 Java 并发编程！
如果你有任何问题或者建议，欢迎在评论区留言，我们一起探讨！ 祝你编程愉快！
