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免费学习笔记（深入）”；
- 构造时指定参与线程总数：
new CyclicBarrier(3)表示等 3 个线程都调用await() - 可选传入一个
Runnable，它会在最后一个线程到达时、**所有线程被唤醒前**执行（常用于汇总、日志或资源预热） - 调用
reset()可强行重置屏障，但会中断所有正在等待的线程，引发BrokenBarrierException，慎用
多个线程共享同一个 CyclicBarrier 实例时要注意什么
多个线程共用一个 CyclicBarrier 实例是标准用法，但容易忽略其线程安全性边界：它本身是线程安全的，但屏障行为依赖所有参与者严格遵循约定。
典型陷阱是线程复用（比如从线程池提交任务），导致同一物理线程多次参与不同轮次的等待，而未意识到屏障状态已被重置或破损。
- 确保每个任务逻辑上“属于同一批协作”，避免跨批次混用同一个
barrier - 不要在
Runnable回调中修改共享变量而不加同步——虽然回调由最后一个线程执行，但它与其他线程的后续操作无 happens-before 关系 - 若线程池中任务数量不确定，建议每次协作新建
CyclicBarrier，或用更高级抽象如Phaser
对比 CountDownLatch：什么时候该换用 CyclicBarrier
CountDownLatch 是一次性倒计时门栓，适合“一个线程等多个线程完成”；而 CyclicBarrier 是循环集合点，适合“多个线程互相等待彼此到达某一阶段”。两者语义不同，不能简单替换。
例如做分段计算：每轮每个线程处理一部分数据，然后全部停在屏障处交换中间结果；下一轮再基于新数据继续——这种迭代式协同，CountDownLatch 无法自然支持。
- 需要多次重复同步 → 选
CyclicBarrier - 只需一次等待全部完成 →
CountDownLatch更轻量 - 需要动态增减参与者 → 考虑
Phaser，它支持注册/注销线程
await() 更影响最终稳定性。 
