cyclicbarrier 的循环同步逻辑核心是“固定目标、动态计数、代次隔离”：parties 为 final 不可变，锚定协作规模；count 动态递减归零后重置，实现轮次循环；generation 隔离各轮等待队列，broken 状态绑定代次，保障多阶段任务的一致性与可控性。
CyclicBarrier 的循环同步逻辑，核心在于“固定目标、动态计数、代次隔离”。它不靠修改参与线程数来适应变化，而是通过不可变的 parties 锚定协作规模，再用可变的 count 和隐式的 Generation 管理每一轮等待状态，从而在多阶段任务中保障所有线程行为一致、触发时机确定、执行节奏可控。
parties 固定：同步契约的基石
初始化时传入的 parties 值被声明为 final，全程不可更改。这不是限制，而是承诺——它明确定义了“多少个线程必须到场，这一轮才算齐整”。这种不可变性带来三个实际好处：
- 避免运行时因线程数量误增/误减导致的永久阻塞或提前释放
- 使 reset() 操作有明确依据：重置后的目标仍是原始 parties，不会漂移
- 让 barrierCommand 的执行条件始终可预测——只在第 parties 个 await() 调用时触发
count 动态递减：每轮独立的状态跟踪
count 是真正参与计数的变量，初始值等于 parties，每次 await() 调用后减一。关键点在于：
- count 归零即表示本轮达成，屏障开启，所有等待线程被唤醒
- 唤醒后，count 自动重置为 parties，准备下一轮——这就是“循环”的实质
- 即使某线程 await() 失败（如中断），count 不会回退，而是进入 broken 状态，确保后续调用立即失败，防止状态混乱
Generation 代次管理：隔离不同轮次的等待队列
CyclicBarrier 内部用静态内部类 Generation 标识当前“局”。每当 count 归零并执行完 barrierCommand 后，会创建新 Generation，并唤醒所有在旧 Generation 中等待的线程。这意味着：
- 上一轮未完成的等待线程（比如刚调用 await() 就被中断）不会干扰下一轮计数
- 不同轮次的线程天然分组，彼此等待队列互不交叉
- broken 状态也绑定在当前 Generation 上，reset() 实际是新建 Generation 并重置 count，而非清空历史
屏障动作与异常传播：统一出口保障一致性
barrierCommand 在每轮 count 归零后、唤醒前执行，且仅由最后一个到达的线程调用。这种设计确保：
- 汇总操作、资源检查、日志记录等关键逻辑只执行一次，不重复也不遗漏
- 若 barrierCommand 抛出异常，整个屏障立即 broken，所有等待线程收到 BrokenBarrierException，避免部分线程继续而其他卡住
- 任一线程 await() 超时或中断，都会导致当前 Generation broken，其余等待者不再苦等，而是快速失败退出
