CyclicBarrier 的核心价值在于支持多轮线程同步协作，确保所有线程到齐后才共同推进，适用于分批处理、阶段计算等场景；它通过 await() 实现集体就位，可配置屏障动作、超时机制，并天然可重用。
CyclicBarrier 的核心价值在于让多个线程“齐步走”——不是谁先做完谁先走，而是所有人到齐才一起迈下一步，且这一步可以重复多次。它不像 CountDownLatch 用完即废，而是天然支持多轮协作，特别适合分批处理、阶段式计算、协同初始化等场景。
任务组同步：确保所有线程按周期集体就位
创建 CyclicBarrier 时指定参与线程数（parties），就是定义一个“任务组”的规模。每个线程完成自身工作后调用 await()，即宣告“我已就位”。此时该线程会被挂起，直到组内最后一个线程也调用 await()，屏障才被触发，所有等待线程同时恢复执行。
- 必须保证每个线程在每轮中**恰好调用一次 await()**；少调会导致部分线程永久阻塞，多调可能提前触发或引发 BrokenBarrierException
- 推荐配合线程池使用，例如 FixedThreadPool，避免手动管理线程生命周期带来的不确定性
- 可通过 getNumberWaiting() 实时查看当前还有几个线程没到，便于调试和监控
屏障动作：在全体就位瞬间执行关键协调逻辑
构造 CyclicBarrier 时传入的 Runnable 参数，会在所有线程到达后、释放前由最后一个到达的线程**串行执行**。这是做汇总、校验、状态更新或日志记录的理想位置。
Java注释规范Skills
下载
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 屏障动作应轻量，控制在毫秒级完成；若耗时过长，会成为整个任务组的性能瓶颈
- 常见用途包括：合并各线程的局部计算结果、刷新共享统计指标、检查是否需要终止后续轮次、写入中间快照等
- 动作中抛出未捕获异常会使屏障破损（isBroken() 返回 true），后续 await() 都会立即抛出 BrokenBarrierException
异常与超时：保障任务组健壮运行
await() 方法可能抛出 InterruptedException 或 BrokenBarrierException，实际编码中不可忽略：
- 遇到 InterruptedException，通常意味着线程被外部中断，需决定是退出当前轮次还是重试
- BrokenBarrierException 表明屏障已被破坏（如某线程超时或中断离开），此时屏障不可再用，需重建或统一协调恢复
- 强烈建议使用带超时的 await(long timeout, TimeUnit unit)，防止某个子任务卡死拖垮整体进度
重用与重置：真正实现“循环”协作
CyclicBarrier 天然可重用——一轮结束后自动重置计数器，无需重新 new 实例。但若发生破损（broken），则无法自动恢复，必须显式重建。
- 正常流程下，每轮 await() 返回后，屏障即可用于下一轮，无需额外操作
- 若某轮因异常中断，可通过 isBroken() 判断状态，并在必要时新建 CyclicBarrier 实例继续流程
- 注意：reset() 方法虽存在，但仅适用于极少数需强制恢复破损屏障的场景，多数情况下重建更清晰安全
