cyclicbarrier的屏障动作回调在所有线程到达屏障后由最后一个线程同步执行一次，用于阶段汇总、日志记录等；需避免抛异常、耗时操作及依赖执行线程身份，必要时可用reset()容错重启。
CyclicBarrier 的屏障动作回调（barrier action）是其实现“同步+汇报”能力的关键机制，它在所有参与线程都调用 await() 到达屏障点后、释放线程前**恰好执行一次**，且由**最后一个到达的线程**负责触发。这使得它天然适合做阶段汇总、日志记录、状态检查或触发下游通知等中间同步操作。
屏障动作的定义与执行时机
屏障动作是一个 Runnable 实例，在构造 CyclicBarrier 时通过带两个参数的构造函数传入：
CyclicBarrier(int parties, Runnable barrierAction)- 该 barrierAction 不在独立线程中运行，而是由某个工作线程（通常是最后一个调用
await()的线程）在临界区内同步执行 - 执行完成前，所有其他等待线程仍处于阻塞状态；执行完毕后，所有线程才被同时唤醒继续运行
典型应用场景：每轮计算后的结果汇总
例如多个线程并行处理数据分片，每完成一轮迭代，需将各自局部结果合并为全局快照：
- 每个线程维护自己的
localSum、localCount - 屏障动作中，由最后一个线程收集全部线程的局部值，计算总和、平均值或写入共享容器
- 避免额外加锁——因为此时只有它一个线程在执行 barrierAction，天然线程安全
注意事项与常见陷阱
屏障动作虽简洁有力，但使用不当易引发问题：
- 若 barrierAction 中抛出未捕获异常（如
RuntimeException），整个屏障会被标记为“破损（broken）”，后续所有await()调用将立即抛出 BrokenBarrierException - 不建议在 barrierAction 中执行耗时操作（如远程调用、磁盘 I/O），否则会拖慢所有线程的释放，影响整体吞吐
- 不能依赖 barrierAction 的执行线程身份做业务逻辑判断（比如“必须是主线程执行”），因为实际执行者是动态的最后一个到达者
- 若需异步通知，可在 barrierAction 内启动新线程或提交到线程池，但要确保异常隔离
进阶技巧：结合 reset() 主动干预屏障状态
虽然 CyclicBarrier 默认自动重置，但在某些异常流程中可主动调用 reset() 强制清空当前等待态：
- 当检测到某线程因超时或中断提前退出，导致屏障无法正常触发时，可调用
barrier.reset()恢复可用状态 - 注意：reset() 会使所有已阻塞线程收到 BrokenBarrierException，需配合 try-catch 处理
- 适用于需要容错重启的长期运行任务（如周期性批处理服务）
