cyclicbarrier 的 await() 必须在每个线程中显式调用，因其仅提供被动“门禁”机制，不自动拦截线程；漏调将导致提前执行、回调未触发或屏障破损。

为什么 CyclicBarrier 的 await() 必须在每个线程里显式调用

CyclicBarrier 不会自动拦截线程，它只提供一个“门禁”机制：谁调用 await()，谁就排队等其他线程。如果某个线程漏掉这一步，它会直接越过同步点继续执行，导致逻辑错乱或数据不一致。

常见错误现象包括：部分线程提前进入后续处理、计数器未触发 Runnable 回调、甚至 BrokenBarrierException 在其他线程中抛出（因某线程中断或超时后破坏了屏障状态）。

• 所有参与协同的线程，必须在到达同步点时调用一次且仅一次 barrier.await()
• 建议把 await() 放在 try-catch 块中，捕获 InterruptedException 和 BrokenBarrierException
• 若使用带超时的 await(long, TimeUnit)，需注意超时后该线程会继续执行，但屏障可能已处于破损状态

如何正确初始化 CyclicBarrier 并复用它多次

CyclicBarrier 的“cyclic”体现在它可被重复使用——一旦所有线程完成一次 await()，内部计数器会重置，下一轮等待可立即开始。但前提是没发生破损（如某线程中断、超时或异常退出）。

初始化时传入的线程数是硬约束：若实际参与线程少于该值，await() 会永久阻塞（除非超时）；若多于该值，则多余线程调用 await() 会立即抛出 BrokenBarrierException。

Java注释规范Skills

当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。

下载

• 构造时指定参与线程总数：new CyclicBarrier(3) 表示等 3 个线程都调用 await()
• 可选传入一个 Runnable，它会在最后一个线程到达时、**所有线程被唤醒前**执行（常用于汇总、日志或资源预热）
• 调用 reset() 可强行重置屏障，但会中断所有正在等待的线程，引发 BrokenBarrierException，慎用

多个线程共享同一个 CyclicBarrier 实例时要注意什么

多个线程共用一个 CyclicBarrier 实例是标准用法，但容易忽略其线程安全性边界：它本身是线程安全的，但屏障行为依赖所有参与者严格遵循约定。

典型陷阱是线程复用（比如从线程池提交任务），导致同一物理线程多次参与不同轮次的等待，而未意识到屏障状态已被重置或破损。

• 确保每个任务逻辑上“属于同一批协作”，避免跨批次混用同一个 barrier
• 不要在 Runnable 回调中修改共享变量而不加同步——虽然回调由最后一个线程执行，但它与其他线程的后续操作无 happens-before 关系
• 若线程池中任务数量不确定，建议每次协作新建 CyclicBarrier，或用更高级抽象如 Phaser

对比 CountDownLatch：什么时候该换用 CyclicBarrier

CountDownLatch 是一次性倒计时门栓，适合“一个线程等多个线程完成”；而 CyclicBarrier 是循环集合点，适合“多个线程互相等待彼此到达某一阶段”。两者语义不同，不能简单替换。

例如做分段计算：每轮每个线程处理一部分数据，然后全部停在屏障处交换中间结果；下一轮再基于新数据继续——这种迭代式协同，CountDownLatch 无法自然支持。

• 需要多次重复同步 → 选 CyclicBarrier
• 只需一次等待全部完成 → CountDownLatch 更轻量
• 需要动态增减参与者 → 考虑 Phaser，它支持注册/注销线程

CyclicBarrier 的核心复杂点不在 API 使用，而在于对“协作节奏”的建模：你得清楚哪几段逻辑构成一个完整周期，哪些线程必须严格对齐，以及当有人掉队时系统该如何退化。这些设计决策往往比写几行 await() 更影响最终稳定性。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南