CyclicBarrier与线程池配合实现“分工+协同”：线程池负责资源复用与任务调度，CyclicBarrier专注多线程在关键点的集体等待与阶段推进，适用于多阶段并行中“分头算→汇总→再分头算”的场景。
CyclicBarrier 和线程池配合，本质是“分工+协同”：线程池管资源复用与任务调度，CyclicBarrier 管多线程在关键点的集体等待与阶段推进。它不替代 CountDownLatch，也不用于主流程等待，而是专注解决“多个线程算完一部分，必须一起迈向下一步”的问题。
按维度切分任务，交给线程池执行
多维数据（如 4D 张量、3D 矩阵）适合按某维（如 i-j 平面、x-y 块）拆成 N 个子任务，每个子任务封装为 Runnable 或 Callable，提交给固定大小的线程池（如 Executors.newFixedThreadPool(N)）。每个任务知道自己处理哪一段数据，避免竞争和越界。
- 例如三维数组 data[x][y][z]，按 (x, y) 分块，每块由一个线程处理 z 维循环
- 不要让所有线程都操作同一片内存；用局部变量或线程私有缓冲区保存中间结果
- 线程池大小建议匹配 CyclicBarrier 的 parties 数——若 barrier(5)，就只提交 5 个任务，否则会永久阻塞
用 CyclicBarrier 控制阶段性同步
CyclicBarrier 不参与计算，只设“关卡”。每个子任务在完成本阶段工作（如本地求和、预处理、z 维部分卷积）后，调用 barrier.await()。全部到达后，屏障打开，所有线程继续；若设置了 barrierAction，则由其中一个线程执行汇总逻辑（如把 5 个局部 sum 加总写入全局结果）。
- 屏障动作要轻量：适合原子计数器累加、ConcurrentMap.put、简单校验，避免 IO 或长事务
- 必须捕获 BrokenBarrierException（某线程异常退出导致屏障损坏）和 InterruptedException（线程被中断），及时熔断或恢复状态
- 推荐使用带超时的 await(long timeout, TimeUnit unit)，比如 30 秒，防止单点假死拖垮整批
多阶段并行时重复利用 barrier
金融对账、迭代算法、多轮归一化等场景常需多次“分头算 → 汇总 → 再分头算”。CyclicBarrier 天然可重用，比反复 new CountDownLatch 更高效、GC 压力更小。
立即学习“Java免费学习笔记（深入）”；
- 每次新一批任务开始前，可显式调用 barrier.reset()，或直接新建实例（更利于生命周期追踪）
- 不要依赖自动重置做跨批次复用——若上一批未正常结束（如 BrokenBarrierException 未处理），下一批 await 可能立即失败
- 秒杀、对账等高可靠场景中，常搭配 barrierAction 做一致性校验：任一子任务返回空数据，就在 barrierAction 中抛出异常，触发整体回滚
注意线程安全与常见陷阱
共享状态是并发隐患的源头。即使用了 CyclicBarrier，也不能放松对共享资源的保护。
- 屏障动作里写的全局变量，必须是线程安全的（如 AtomicInteger、ConcurrentHashMap），或加锁
- 避免在 await() 后直接读取其他线程刚写入的非 volatile/非安全发布字段——屏障只保证“到达顺序”，不保证内存可见性（除非 barrierAction 已完成写操作）
- 不要在线程池 shutdown 后还往里面 submit 新任务，也不要在线程已终止后再调用其 barrier.await()
