CyclicBarrier 适用于多阶段并行计算，支持重复使用，每轮等待所有线程到达后自动重置；CountDownLatch 不可重用，频繁新建实例会增加开销和出错风险。
CyclicBarrier 不是“等所有线程跑完就结束”，而是“等所有线程到达同一阶段点才一起往下走”——它天然适合分阶段并行计算，比如多轮迭代、多批次数据处理、协同初始化等场景。
为什么不能直接用 CountDownLatch 替代 CyclicBarrier？
CountDownLatch 是一次性计数器，await() 后无法重置；而 CyclicBarrier 支持重复使用，每调用一次 await() 就代表一个线程抵达当前阶段，全部到达后自动释放并重置内部状态。如果你要做 5 轮并行计算，每轮都需等待全部线程就位再同步推进，CyclicBarrier 是更自然的选择。
- 错误做法：用
CountDownLatch每轮 new 一个新实例 → 对象创建开销 + GC 压力 + 逻辑易错 - 正确做法：复用同一个
CyclicBarrier实例，配合reset()（慎用，会中断等待线程）或依赖其默认循环行为 - 注意：
CyclicBarrier构造时传入的Runnable（屏障动作）只在最后一人到达时执行一次，且在所有线程被释放前运行 —— 这很适合做阶段汇总、日志记录或状态检查
如何安全地在多阶段中复用 CyclicBarrier？
核心是理解它的“循环”机制：只要没被 broken（比如某线程超时或被中断），每次所有参与者调用 await() 后，它就自动回到初始计数状态。不需要手动 reset，也不建议主动调用 reset()，因为这会唤醒所有等待线程并抛出 BrokenBarrierException。
- 每个线程在每阶段末尾必须调用
await()，缺一不可；漏调会导致其他线程永久阻塞 - 如果某线程在
await()时抛出BrokenBarrierException，说明栅栏已被破坏（例如有线程超时退出或被中断），此时整个阶段失败，需统一处理（如清空结果、重试或退出） - 推荐为
await()加超时：barrier.await(30, TimeUnit.SECONDS)，避免单点故障拖垮整组计算 - 不要在线程池中混用不同生命周期的
CyclicBarrier实例，容易因复用混乱导致阶段错位
一个典型的三阶段并行计算示例
假设你有 4 个线程并行处理一批数据，每轮分三个阶段：预处理 → 计算 → 合并。每阶段都必须等全部线程完成当前步骤才能进入下一步：
Runnable
- 别在屏障动作里直接修改普通
int或List，要用AtomicInteger、ConcurrentHashMap或加锁 -
await()抛出的InterruptedException和TimeoutException必须显式捕获并决策：是中断当前线程、标记失败，还是重试？不处理会导致阶段静默卡死 - 如果某线程在阶段中抛异常未被捕获，它不会自动调用
await()，其他线程将无限等待 —— 建议用 try-finally 包裹关键路径，确保await()总被执行（或明确标记失败） - 调试时可打印
barrier.getNumberWaiting()，但仅限开发环境，生产中避免频繁调用影响性能
真正难的不是写对语法，而是让每个线程在每个阶段都“准时抵达、正确离开、失败可知”。栅栏本身很轻量，但它的契约需要所有人严格遵守。
