CyclicBarrier 的 reset() 会强制中断所有等待线程并抛出 BrokenBarrierException，无法安全用于阶段性失败后的重置；应改用新建屏障、volatile 阶段标识或升级为 Phaser 实现可靠分阶段同步。
CyclicBarrier 的 reset 并不适用于“阶段性失败后安全重置”——这是个常见误解。reset() 方法会强行中断所有等待线程，触发 BrokenBarrierException，且无法区分哪些线程已执行、哪些未开始，容易导致状态不一致或资源泄漏。真正可靠的阶段性重置，应绕过 reset，改用“屏障重建 + 状态隔离”策略。
用新 CyclicBarrier 替代 reset：避免中断风暴
reset() 会唤醒并异常所有阻塞线程，破坏协作逻辑。更稳妥的做法是：在检测到阶段性失败（如某任务抛出业务异常）后，主动丢弃旧 barrier，新建一个同规格的实例供下一轮使用。
- 每次“阶段开始前”创建新的
CyclicBarrier，例如：barrier = new CyclicBarrier(participants, onPhaseComplete) - 各任务捕获自身异常，在 finally 块中调用
barrier.await()（确保即使失败也参与同步），但仅成功任务才提交结果 - 主控线程在
onPhaseComplete中检查上一阶段结果聚合状态；若失败，直接初始化新 barrier，不复用旧实例
结合 volatile 标志位实现阶段感知
单靠 barrier 无法表达“当前处于第几阶段”，需额外状态标识来隔离不同轮次的执行上下文。
- 定义
volatile int currentPhase = 0，每次新阶段开始前currentPhase++ - 每个任务在执行前读取当前 phase 值，并将结果写入以 phase 为 key 的
ConcurrentHashMap<Integer, List<Result>> - 当某任务因异常退出，它仍会 await 当前 barrier；屏障触发后，主逻辑根据
currentPhase查对应结果集，决定是否重试或跳过该阶段
用 Phaser 替代 CyclicBarrier（推荐升级方案）
Phaser 是更现代的可重用同步器，天然支持动态注册/注销、分阶段终止和无损重置：
- 调用
phaser.arriveAndDeregister()让失败任务主动退出当前阶段，不影响其余参与者 - 通过
phaser.getPhase()获取当前阶段号，比手动维护标志更可靠 - 若需整体重启，调用
phaser.bulkRegister(n)即可重新注册 n 个参与者，无需中断任何线程 - 示例：阶段性计算中，任一任务失败时调用
phaser.arriveAndDeregister()，其余任务继续 await；主控线程在onAdvance()中检查phaser.getRegisteredParties()，若小于预期，则新建 phaser 或补注册缺失参与者
关键提醒：reset 的真实代价
reset 不是“清空重来”，而是“强制熔断”：
- 所有已 await 但尚未被唤醒的线程，收到
BrokenBarrierException，无法知道是失败还是重置导致 - 已通过 barrier 的线程不会受影响，但它们可能已修改共享状态，而 reset 后的新轮次又从头开始，造成重复处理或数据覆盖
- 如果 barrier 关联了 Runnable（如汇总逻辑），reset 会丢弃该回调，且无任何通知机制
