必须用 cyclicbarrier 而不是 countdownlatch 的场景是多轮重复同步，即每轮所有线程必须互相等待到齐才共同推进，因其可自动重置复用，而 countdownlatch 一次性不可重用。
什么时候必须用 CyclicBarrier 而不是 CountDownLatch
当你需要「多轮重复同步」，且每轮都要求所有线程互相等待到齐再一起往下走时，CyclicBarrier 是唯一合理选择。比如：模拟多轮游戏加载、分阶段迭代计算（如数值模拟的每一轮时间步）、并行训练中每轮梯度同步后更新模型参数。
CountDownLatch 是一次性倒计时，用完即废；而 CyclicBarrier 在所有线程 await() 返回后自动重置，下一轮可直接复用——这点在循环任务中省去了反复 new 对象的开销和状态管理麻烦。
- 错误做法：用
CountDownLatch模拟多轮等待 → 每轮都要重建实例，且无法保证“所有线程同时出发” - 典型信号：日志里出现 “第1轮完成”、“第2轮完成”… 且每轮逻辑结构一致 → 这就是
CyclicBarrier的主场
barrierAction 参数到底该放什么逻辑
这是 CyclicBarrier 构造时第二个 Runnable 参数，它只由「最后一个到达的线程」执行一次，且在所有线程被唤醒前运行。适合放汇总、校验、日志或轻量级协调动作。
别把它当成“回调钩子”乱塞耗时操作——如果这里阻塞太久，其他线程会卡在 await() 返回前，整体吞吐就垮了。
立即学习“Java免费学习笔记（深入）”；
