必须用 CyclicBarrier 而不是 CountDownLatch 的场景是多轮重复同步，即每轮所有线程必须互相等待到齐才共同推进，因其可自动重置复用，而 CountDownLatch 一次性不可重用。
什么时候必须用 CyclicBarrier 而不是 CountDownLatch
当你需要「多轮重复同步」，且每轮都要求所有线程互相等待到齐再一起往下走时，CyclicBarrier 是唯一合理选择。比如：模拟多轮游戏加载、分阶段迭代计算（如数值模拟的每一轮时间步）、并行训练中每轮梯度同步后更新模型参数。
CountDownLatch 是一次性倒计时，用完即废；而 CyclicBarrier 在所有线程 await() 返回后自动重置，下一轮可直接复用——这点在循环任务中省去了反复 new 对象的开销和状态管理麻烦。
- 错误做法：用
CountDownLatch模拟多轮等待 → 每轮都要重建实例，且无法保证“所有线程同时出发” - 典型信号：日志里出现 “第1轮完成”、“第2轮完成”… 且每轮逻辑结构一致 → 这就是
CyclicBarrier的主场
barrierAction 参数到底该放什么逻辑
这是 CyclicBarrier 构造时第二个 Runnable 参数，它只由「最后一个到达的线程」执行一次，且在所有线程被唤醒前运行。适合放汇总、校验、日志或轻量级协调动作。
别把它当成“回调钩子”乱塞耗时操作——如果这里阻塞太久，其他线程会卡在 await() 返回前，整体吞吐就垮了。
立即学习“Java免费学习笔记（深入）”；
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 推荐放：打印汇总统计、写入中间结果到共享容器、触发下一轮初始化（如清空缓存）
- 禁止放：网络请求、文件 I/O、数据库写入、长时间 sleep —— 这些会让屏障变成单点瓶颈
- 注意：若
barrierAction抛异常，整个屏障会被标记为 broken，后续所有await()都抛BrokenBarrierException
为什么 await() 有时突然抛 BrokenBarrierException
这不是随机异常，而是屏障被“破坏”的明确信号：要么有线程在等待时被中断（interrupt()），要么 barrierAction 执行失败，要么有人调了 reset() 但其他线程还在等。
关键点在于：只要一个线程出问题，所有正在等或即将等的线程都会收到这个异常——这是设计使然，不是 bug。
- 常见诱因：
Thread.interrupt()被误调用；线程池 shutdownNow() 强制中断工作线程；barrierAction中未捕获 RuntimeException - 应对方式：在
catch (BrokenBarrierException e)块里做清理（如释放资源），然后通常要主动break或return，避免继续跑错逻辑 - 不要忽略它：吞掉这个异常等于放任数据不一致或死锁风险
分区计算 + 汇总场景下的线程数与数据切分陷阱
示例中常看到 DATA_SIZE / THREAD_COUNT 算 chunkSize，但整除不总是成立——最后一块容易漏数据或越界。
更稳妥的做法是用 Math.min(start + chunkSize, data.length) 控制 end 边界，并确保每个线程处理的数据段互斥且全覆盖。
- 危险写法：
end = (i + 1) * chunkSize→ 当DATA_SIZE % THREAD_COUNT != 0时，最后线程可能越界或少算 - 安全写法：
int end = Math.min(start + chunkSize, data.length)，且循环条件保持i - 额外提醒：如果线程数大于数据长度（比如 10 个线程处理 3 个元素），
CyclicBarrier仍会等满 10 个await()，务必检查是否真有必要启动这么多线程
真正难的不是调用 await()，而是想清楚「谁该等谁」「等齐之后谁负责协调」「失败时整个批次怎么收场」——CyclicBarrier 把同步机制封装好了，但业务语义得你亲手对齐。
