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 { 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
是一个非常强大的并发工具，但理解其工作原理和潜在问题，并在实际开发中灵活运用，才能真正发挥它的威力。
以上就是Java中CyclicBarrier的应用场景的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/74940.html
微信扫一扫 
支付宝扫一扫 
