CyclicBarrier是Java中用于多线程同步的工具，允许多个线程在到达某个屏障点时相互等待，直至全部线程就绪后才共同继续执行。与CountDownLatch的一次性不同，CyclicBarrier可重复使用，适用于分阶段、迭代式的并发任务场景。其核心机制是通过await()方法阻塞线程，直到指定数量的线程都调用了await()，此时若设置了barrierAction，则由最后一个到达的线程执行该操作，随后所有线程被释放。常见应用场景包括数据并行处理、图像处理、批处理系统、模拟仿真、游戏加载和性能测试等，尤其适合需要“集体出发”模式的协同任务。使用时需注意BrokenBarrierException异常、barrierAction的轻量化设计、线程中断处理、死锁风险以及reset()方法的安全调用时机，确保同步逻辑的稳定与高效。
Java中的
CyclicBarrier，在我看来，它就是一个让一群线程在某个特定“关卡”前集合，然后一起冲过这个关卡的工具。核心思想很简单：当所有参与者都到达指定点时，它们才能集体继续前进。这在很多需要多线程协同、分阶段完成任务的场景下，简直是量身定制。它不像
CountDownLatch那样“一次性”的倒计时，
CyclicBarrier是可以重复使用的，就像游戏里的一个又一个检查点，每过一关，下一次还能用。
解决方案
CyclicBarrier提供了一种在多线程环境下，让一组线程相互等待，直到所有线程都到达一个共同的屏障点（barrier point）才能继续执行的机制。它的构造函数通常有两种：
CyclicBarrier(int parties)和
CyclicBarrier(int parties, Runnable barrierAction)。这里的
parties指的是需要等待的线程数量。而可选的
barrierAction则是一个
Runnable接口的实现，当所有线程都到达屏障点时，会先执行这个
barrierAction，然后所有线程才会继续各自的执行。
当一个线程调用
CyclicBarrier的
await()方法时，它会被阻塞，直到所有
parties数量的线程都调用了
await()。一旦所有线程都到达，屏障就会被“打破”，所有被阻塞的线程都会被释放，继续它们的任务。更棒的是，这个屏障可以被重置（reset），从而在后续的迭代中再次使用，这正是它“循环”的魅力所在。
import java.util.concurrent.CyclicBarrier;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
public class CyclicBarrierExample {
public static void main(String[] args) {
int parties = 3; // 假设有3个线程参与
CyclicBarrier barrier = new CyclicBarrier(parties, () -> {
// 当所有线程都到达屏障时，会执行这个Runnable
System.out.println("所有线程都到达屏障了，开始下一阶段！");
});
ExecutorService executor = Executors.newFixedThreadPool(parties);
for (int i = 0; i < parties; i++) {
final int taskId = i;
executor.submit(() -> {
try {
System.out.println("任务 " + taskId + " 正在执行第一阶段...");
TimeUnit.SECONDS.sleep((long) (Math.random() * 3)); // 模拟耗时操作
System.out.println("任务 " + taskId + " 完成第一阶段，等待其他任务...");
barrier.await(); // 线程到达屏障点，等待其他线程
System.out.println("任务 " + taskId + " 开始执行第二阶段...");
TimeUnit.SECONDS.sleep((long) (Math.random() * 2)); // 模拟耗时操作
System.out.println("任务 " + taskId + " 完成第二阶段。");
} catch (Exception e) {
System.err.println("任务 " + taskId + " 发生异常: " + e.getMessage());
}
});
}
executor.shutdown();
}
}为什么在多线程协同中，CyclicBarrier常常是更优的选择？
说实话，刚接触并发编程的时候，我总会把
CyclicBarrier和
CountDownLatch搞混。但用多了就发现，它们的设计哲学和应用场景是有些微妙但关键的区别的。
CountDownLatch更像一个一次性的倒计时牌，它允许一个或多个线程等待其他线程完成一系列操作。比如，主线程要等所有子任务都执行完了才能继续。一旦倒计时归零，这个
CountDownLatch就“废”了，不能再用了。
立即学习“Java免费学习笔记（深入）”；
CyclicBarrier则不同，它强调的是“集体行动”和“可重用性”。它让一组线程互相等待，直到所有线程都到达某个同步点，然后一起继续。最关键的是，这个屏障可以循环使用。这在很多分阶段、迭代式处理任务的场景下，简直是绝配。比如，你有一批数据需要分批处理，每个线程处理一部分，处理完当前批次后，所有线程需要等待，等待一个汇总或校验操作完成，然后才能进入下一批次的处理。这时候，
CyclicBarrier的优势就体现出来了，你不需要为每一批次都新建一个同步工具。
跟
Semaphore比呢？
Semaphore主要是控制对共享资源的访问数量，它关注的是“有多少个许可”，而不是“所有人都到齐了没”。
ReentrantLock或
synchronized则更侧重于互斥访问，确保同一时间只有一个线程能进入某个临界区。所以，当你的需求是“大家一起等，一起走”的时候，
CyclicBarrier往往是更直观、更简洁的解决方案。
CyclicBarrier在哪些实际应用场景中能发挥巨大作用？
在我多年的开发经验中，
CyclicBarrier真的解决了不少棘手的问题。
-
数据并行处理与分阶段任务： 这大概是最经典的场景了。设想一下，你有一个巨大的数据集需要处理，为了提高效率，你把数据分成N份，然后启动N个线程去并行处理。但处理完第一阶段后，你可能需要对这些局部结果进行一次全局的汇总、校验或者合并，然后再进入第二阶段的处理。
-
多人游戏或分布式系统中的同步： 在需要多个参与者在某个特定时刻同步状态的场景，
CyclicBarrier
也能派上用场。-
游戏加载： 多人在线游戏里，所有玩家必须加载完地图、模型等资源后，才能一起进入游戏世界。
CyclicBarrier
可以确保所有玩家都准备就绪。 -
分布式事务模拟： 虽然不是真正的分布式事务解决方案，但在模拟某些分布式协调机制（比如两阶段提交的准备阶段）时，可以利用
CyclicBarrier
让所有模拟节点在“准备就绪”后，等待其他节点，然后一起进入“提交”阶段。
-
游戏加载： 多人在线游戏里，所有玩家必须加载完地图、模型等资源后，才能一起进入游戏世界。
并发性能测试： 当你需要模拟大量并发用户同时发起请求时，
CyclicBarrier
是一个非常实用的工具。你可以启动N个线程，让它们都准备好，然后通过CyclicBarrier
让它们在同一时刻发起请求，这样就能更准确地测量系统的并发处理能力。
这些场景的核心共同点是：任务需要分阶段进行，且每个阶段的开始都需要所有参与者都达到一个共同的“就绪”状态。
使用CyclicBarrier时需要注意哪些潜在问题和最佳实践？
CyclicBarrier虽然好用，但在实际应用中也有些“坑”需要注意，以及一些实践经验可以分享。
-
BrokenBarrierException： 这是最常见的一个异常。当一个线程在等待屏障时被中断、超时，或者屏障被重置，甚至其他等待的线程在屏障点抛出了异常，都可能导致其他等待线程抛出
BrokenBarrierException
。这意味着屏障被“打破”了，不再有效。-
处理策略： 通常，当捕获到
BrokenBarrierException
时，意味着当前批次的同步已经失败了，可能需要重新尝试整个批次，或者进行错误日志记录和清理。有时候，你可能需要考虑在await()
方法上使用带超时参数的版本：await(long timeout, TimeUnit unit)
，以避免无限等待。
-
处理策略： 通常，当捕获到
-
barrierAction的执行：
barrierAction
是在最后一个线程到达屏障时，由该线程在所有等待线程被释放之前执行的。这意味着barrierAction
中的代码会阻塞所有即将被释放的线程。-
最佳实践：
barrierAction
应该轻量级、无副作用，并且执行时间短。如果barrierAction
需要执行耗时操作，或者可能抛出异常，那么它可能会拖慢整个同步过程，甚至导致屏障失效。
-
最佳实践：
-
线程中断处理： 和其他同步工具一样，当线程在
await()
时被中断，会抛出InterruptedException
。-
最佳实践： 捕获
InterruptedException
后，通常需要根据业务逻辑决定是重新尝试、清理资源，还是直接退出。记住，当线程被中断时，它的中断状态会被清除，如果需要传递中断信号，应该重新设置中断状态：Thread.currentThread().interrupt();
。
-
最佳实践： 捕获
-
死锁风险： 虽然
CyclicBarrier
本身不太容易直接导致死锁，但如果barrierAction
内部或者参与线程在await()
前后持有了其他锁，并且这些锁的获取顺序不当，仍然可能发生死锁。-
最佳实践： 仔细审查
barrierAction
和参与线程的业务逻辑，确保没有不当的锁获取顺序。
-
最佳实践： 仔细审查
-
重置（reset）的时机：
CyclicBarrier
的reset()
方法可以将其重置为初始状态。但是，如果在有线程正在等待屏障时调用reset()
，这些等待的线程会抛出BrokenBarrierException
。-
最佳实践：
reset()
通常在所有参与线程都完成了当前阶段，并且确定要开始新一轮的循环时调用。在多线程环境下，确保reset()
的调用是安全的，没有线程正在await()
是一个挑战。通常，更稳妥的做法是在一个外部协调线程中，或者在所有工作线程都结束后，再考虑重置。
-
最佳实践：
总的来说，
CyclicBarrier是一个非常强大的并发工具，但理解其工作原理和潜在问题，并在实际开发中灵活运用，才能真正发挥它的威力。
