cyclicbarrier 实现任务组同步需为每组创建独立实例，确保组内线程集体等待、组间完全隔离；必须统一调用 await()，配合 barrieraction 汇总或推进，并妥善处理异常与重置。
用 CyclicBarrier 实现任务组同步，关键在于让每组线程独立等待、集体推进，而不是所有线程混在一起等。它不适用于动态变数或单次等待场景，但特别适合固定分组、多轮协作的结构。
明确分组边界，为每组创建独立屏障
每个任务组对应一个 CyclicBarrier 实例，组内线程数即 parties 参数值。比如 6 个线程分为 2 组（每组 3 人），就该创建两个 CyclicBarrier(3)，不能共用一个 CyclicBarrier(6)——否则会跨组阻塞，破坏分组逻辑。
- 组间完全隔离：A 组线程调用 barrierA.await()，只影响 A 组；B 组调用 barrierB.await()，互不干扰
- 避免共享屏障：若误用单个 CyclicBarrier(6)，只要任意 6 个线程到达就放行，可能 A 组 2 人 + B 组 4 人提前触发，导致组内不同步
- 命名或封装清晰：可用 Map
按组名管理，或为每组定义专属 BarrierHolder 类
每组内部统一调用 await()，且必须全部调用
组内每个线程在完成本阶段任务后，必须无条件调用一次 await()。少调用或异常跳过会导致该组计数器无法归零，其余线程永久阻塞。
Multi-Brain Protocol
下载
一款AI工具，主要用于在主代理响应前，并行运行Kimi K2.5和GPT 5.3 Codex，注入双方观点以增强认知多样性，适合需要提升相关任务效率的用户。
- 放在阶段末尾：例如“数据采集 → await() → 预处理 → await()”，确保该阶段真正结束才进入等待
- 包裹 try-catch：await() 可能抛 BrokenBarrierException 或 InterruptedException，需捕获并决定是否中止当前组任务
- 禁止条件分支跳过：不能写 if (success) barrier.await()，失败线程也应 await() 或调用 barrier.reset() + 显式通知
利用 barrierAction 做组级汇总或状态切换
构造时传入的 Runnable 在该组所有线程到达后、释放前执行，是做组内协调的最佳时机。
- 汇总局部结果：各线程把计算结果写入线程安全容器（如 ConcurrentHashMap 或 AtomicReferenceArray），barrierAction 从中读取并合并
- 触发下一阶段信号：修改共享状态标志位、提交下一批任务到线程池、或唤醒监听器
- 记录日志或监控：打印“第3组完成阶段2，平均耗时127ms”，便于追踪分组进度
注意重用与异常恢复机制
CyclicBarrier 天然支持循环使用，但一旦某组因异常被打破（broken），该屏障实例将不可再用，需重建。
- 自动重置：正常通过后，计数器自动恢复为初始 parties 值，可立即用于下一轮
- 手动修复：若发生 BrokenBarrierException，可通过 barrier.reset() 尝试重置（仅当无线程正在 await 时安全）
- 分组隔离的好处：一组出错不影响其他组，整体系统容错性更强
