CyclicBarrier的reset方法仅重置屏障状态并中断等待线程，不支持自动重试，需上层逻辑主动控制分组、捕获异常、决定重试时机；推荐用Phaser替代以支持动态注册与细粒度阶段重试。
CyclicBarrier 的 reset 方法本身并不支持“失败后自动重试”的语义，它只是强行打破当前等待状态、重置屏障计数器，且会中断所有正在 await 的线程（抛出 BrokenBarrierException）。因此，不能直接依赖 reset 实现“阶段性重试”，而应将其作为手动恢复屏障状态的辅助工具，在上层逻辑中主动控制重试时机与分组。
理解 reset 的真实行为
reset 会：
- 立即唤醒所有阻塞在 await() 上的线程，并使其抛出 BrokenBarrierException；
- 将内部计数器重置为初始值（parties），屏障进入“未触发”状态；
- 不恢复已执行但未完成的任务，也不重跑任何线程——它只重置同步点，不管理业务逻辑。
这意味着：reset 是一个“清场+重启同步门”的操作，不是“重试控制器”。你要自己决定哪些任务该重跑、何时调用 reset、哪些线程该重新参与下一轮 await。
按阶段分组 + 主动异常捕获 + reset 重置
典型模式是将一批任务划分为逻辑阶段（如“预加载 → 校验 → 提交”），每个阶段用一个 CyclicBarrier 同步。若某阶段内任一任务失败，则捕获异常、调用 reset 清理屏障，并由主控逻辑决定是否重试该阶段：
- 启动 N 个线程执行同一阶段任务，各自调用 barrier.await()；
- 任意线程抛出非 BrokenBarrierException（如业务校验失败、网络超时），则由该线程或协调者调用 barrier.reset()；
- 其他线程因 await 被中断而收到 BrokenBarrierException，可统一 catch 并退出本轮；
- 主流程判断重试策略（如重试次数 ≤ 3），若允许，则重新创建/重置 barrier，拉起新一批线程重跑该阶段。
避免 reset 引发的竞态与泄漏
reset 不是线程安全的“重试开关”，需注意：
- 不要在 await 中间随意调用 reset —— 可能导致部分线程已通过、部分被中断，状态不一致；
- reset 后必须确保没有线程仍在执行旧 await，否则可能触发 IllegalStateException 或静默失败；
- 推荐配合 volatile boolean running / AtomicInteger retryCount 控制重试生命周期，而非仅靠 barrier 状态；
- 更稳妥的做法是：每阶段使用新实例的 CyclicBarrier（无 reset），失败即丢弃旧 barrier，新建一个用于下一轮。
替代建议：用 Phaser 更自然地支持动态注册与阶段重试
如果重试场景频繁、阶段边界灵活，CyclicBarrier 的固定 parties 和 reset 的粗暴性会成为负担。Phaser 更合适：
- 支持动态 register/unregister 线程，可精准控制每轮参与重试的成员；
- onAdvance() 可自定义阶段结束逻辑，失败时返回 false 即阻止进入下一阶段；
- forceTermination() 类似 reset，但配合 arriveAndDeregister() 可实现“失败线程退出、其余重试”的细粒度控制。
例如：各任务执行完调用 phaser.arriveAndAwaitAdvance()，若某任务失败，设置全局失败标记，下一轮只让未失败线程 re-register 并继续。
