cyclicbarrier 适合做迭代同步点，因其在每阶段强制线程汇合并执行单次汇总回调，天然适配多智能体决策、分布式训练等周期协同场景。
为什么 CyclicBarrier 适合做迭代同步点
CyclicBarrier 的核心价值不是“等所有线程跑完”，而是“在每个指定阶段强制所有线程汇合并继续”。它天然匹配“每轮迭代后汇总结果”这种周期性协同场景——比如模拟多智能体每步决策后交换状态、分布式训练每 epoch 后聚合梯度、或并行数值计算中每轮更新后的校验。关键在于 barrier.await() 是阻塞点，且可选传入 Runnable 作为“汇合时一次性执行的汇总逻辑”，这个回调只由最后一个到达的线程触发，避免了竞态和重复执行。
如何安全地在 barrier 回调里汇总各线程的局部结果
必须确保每个线程把本轮计算结果写入**线程安全的共享容器**，且仅在 barrier 回调中读取——不能在回调里再调用其他线程的 getter 方法，否则可能读到未写入或中间状态。常见错误是让线程直接往 ArrayList 或普通数组写，导致 ConcurrentModificationException 或数据丢失。
- 推荐用
AtomicIntegerArray、ConcurrentHashMap或预分配好大小的volatile Object[]存储各线程的局部结果 - 在 barrier 的
Runnable中遍历该容器，做 sum/max/average 等汇总，结果存入全局volatile变量或AtomicReference - 务必注意：回调里的代码是单线程执行的，但它的执行时机依赖于“最后一个线程调用
await()”，所以不要在回调里做耗时操作（如 IO、锁等待），否则会卡住所有线程
一个典型错误：在 await() 前就修改共享结果变量
常见误写是线程算完立刻更新全局变量，再调用 barrier.await()。这会导致：1）其他线程还没算完，全局变量已被覆盖；2）多个线程同时写，结果不可预测。正确顺序只能是：计算 → 写入线程安全的局部槽位 → barrier.await() → （由回调统一读取所有槽位）→ 汇总 → 更新最终结果。
示例片段：
// ✅ 正确：每个线程写自己的槽位 int threadId = Thread.currentThread().getId() % numThreads; localResults.set(threadId, computeStep(step)); // 阻塞直到全部到达 barrier.await(); // ❌ 错误：这里不是回调！每个线程都会执行，造成竞争 // finalResult += localResults.get(threadId); // 千万别这么写
如何处理某线程在 await() 时被中断或超时
CyclicBarrier 对异常很敏感：一旦任一线程在 await() 中抛出 InterruptedException 或 BrokenBarrierException，整个屏障就进入“破损”状态，后续所有 await() 都会立即抛 BrokenBarrierException。这意味着你必须在每个线程的 try-catch 中重置屏障或退出循环，否则后续迭代会全部失败。
- 捕获
InterruptedException后建议调用barrier.reset()（注意：这会丢弃当前等待的所有线程） - 更稳妥的做法是用带超时的
await(long, TimeUnit)，并在超时后主动barrier.reset()+ 记录日志 - 若业务允许部分线程失败，可在 barrier 回调中检查是否所有槽位都有值，缺失则用默认值填充，避免阻断整体流程
最易被忽略的是：CyclicBarrier 的“可重用”特性只有在所有线程都成功通过一次 await() 后才真正生效；任意一次破损都需要显式 reset，而 reset 本身不是原子操作——如果多个线程同时判断破损并调用 reset，可能引发意外行为。实际使用中，建议用单个监控线程负责 reset，或直接设计为“失败即终止”。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
