cyclicbarrier 的核心是让 cpu 在该忙时高效运转、不该忙时彻底休眠，通过 jvm 底层 condition 队列挂起线程避免空转，支持循环复用、超时熔断与阶段化流水线协同。
用 CyclicBarrier 替代死等，核心不是“压榨 CPU”，而是让 CPU 在该忙的时候高效运转、不该忙的时候彻底休眠——避免空转轮询消耗算力，同时保障多节点协作的精确同步。
明确屏障点，把“等齐”逻辑从代码里抽出来
暴力死等（比如 while(!ready) Thread.sleep(10)）会让线程持续抢占调度器、触发上下文切换、浪费 cache 和分支预测资源。CyclicBarrier 把等待交给 JVM 底层的 Condition 队列，线程在未就绪时直接挂起，不消耗 CPU 周期。
- 每个计算节点启动时注册为一个 party，总数在初始化时确定（如 8 个 Worker 节点 → parties = 8）
- 所有节点完成本地子任务后统一调用 barrier.await()，而不是各自查共享变量或轮询 RPC 状态
- 栅栏打开瞬间，所有线程被 原子唤醒，无竞争、无延迟累积
配合阶段化流水线，让 CPU 始终有活干
单次同步只是起点。CyclicBarrier 可循环的本质，让它天然适配分阶段计算：阶段 A 计算 → 全局同步 → 阶段 B 汇总 → 再同步 → 阶段 C 校验……每阶段之间无缝衔接，CPU 不会因等待而闲置。
- 例如：5 个节点并行做特征提取（阶段1），全部 await 后，由 barrierCommand 触发一次轻量聚合（如校验 checksum），再进入阶段2的模型推理
- 每轮 barrier 自动重置，无需 new 对象或清状态，避免 GC 压力干扰 CPU 密集型任务
- 若某阶段需动态调整参与节点数（如故障剔除），可搭配 tryAdvance 或自定义 reset 逻辑，不破坏整体节奏
绑定超时与熔断，防止局部卡死拖垮全局吞吐
物理服务器算力是刚性的。一个节点网络抖动或 GC 暂停，若无限等待，整条流水线就停滞——这不是压榨，是锁死。
- 一律使用 await(long timeout, TimeUnit unit)，超时时间设为该阶段 P99 耗时 × 1.5（如通常 800ms 完成，则设 1200ms）
- 超时触发 BrokenBarrierException，立即执行降级逻辑（如跳过该节点数据、用默认值填充），保证其他节点继续推进
- 异常发生后调用 barrier.reset() 主动重置，避免残留状态阻塞下一轮；reset 是线程安全的，可在任意节点调用
与底层调度对齐，减少内核态开销
CyclicBarrier 基于 ReentrantLock + Condition 实现，其阻塞/唤醒走的是 JVM 的 park/unpark 机制，最终映射为 futex 系统调用。相比用户态自旋或频繁 syscalls，它更贴近 Linux CFS 调度器的预期行为。
- 避免在 barrier.await() 外层再套 synchronized 或手动 lock，防止锁嵌套放大争用
- 确保 barrier 实例在各节点间不跨 JVM 共享（分布式场景下每个节点持本地实例），状态隔离，不依赖网络同步状态
- 高并发下可预热 barrier（如首次 await 前调用一次 dummy await），减少首次调用时的类加载和队列初始化开销
