cyclicbarrier 的核心优势在于天然可循环重用，无需手动重置；每次所有线程调用 await() 后自动触发 barrier action 并重置状态，支持周期性分批并行任务。
CyclicBarrier 的重置能力是它区别于 CountDownLatch 的核心优势——它能被重复使用，特别适合周期性、分批次的并行计算场景。关键不是“手动重置”，而是利用其天然可循环的特性，在每次批次完成后自动进入下一轮等待，无需重建对象。
理解 CyclicBarrier 的“循环”本质
CyclicBarrier 一旦所有线程到达屏障点（调用 await()），就会触发可选的 barrier action（如汇总结果），然后自动重置内部状态，允许下一批线程再次调用 await() 并阻塞等待。这个过程是原子且线程安全的，不需要显式调用 reset() 方法（除非异常中断后需强制恢复）。
常见误区：用 reset() 主动重置往往破坏正常流程——它会唤醒所有正在 await() 的线程并抛出 BrokenBarrierException，适用于异常恢复，而非常规周期执行。
构建周期性分批任务的标准结构
典型模式是外层控制批次循环，内层启动固定数量的工作线程协作完成单批任务：
- 初始化 CyclicBarrier 时指定参与线程数（如 4 个 worker）和 barrier action（如汇总本批结果）
- 每轮 for 循环中，启动 N 个线程，每个线程执行子任务后调用 barrier.await()
- 当第 N 个线程到达，barrier action 执行，所有线程继续；屏障自动就绪，迎接下一轮
- 批次间无需 sleep 或 wait，靠线程调度自然衔接；若需节奏控制，可在 barrier action 后统一延时
处理异常与中断的稳健做法
单个线程在 await() 中被中断或超时失败，会导致整个批次失败（所有线程收到 BrokenBarrierException）。因此：
- 务必捕获 BrokenBarrierException 和 InterruptedException，并决定是否重试本批或终止流程
- 若某批因异常中断，可通过 barrier.isBroken() 检查状态；必要时用 barrier.reset() 强制恢复，但需确保无线程仍在 await()
- 推荐在 barrier action 中做结果校验，失败则抛出 RuntimeException，同样触发中断机制，便于上层统一处理
一个简明示例：每批 3 个线程计算数组分段和
假设有 12 个数据，按每批 3 个线程并行处理 3 个分段（共 4 批），每批完成后打印总和：
CyclicBarrier barrier = new CyclicBarrier(3, () -> {System.out.println("本批完成，当前总和：" + batchSum.get());
batchSum.set(0); // 重置汇总变量
});
for (int round = 0; round for (int i = 0; i new Thread(() -> {
int localSum = computeSegment();
batchSum.addAndGet(localSum);
try { barrier.await(); } catch (Exception e) { /* 处理 */ }
}).start();
}
TimeUnit.MILLISECONDS.sleep(10); // 确保线程全部启动（实际建议用 latch 控制）
}
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
