cyclicbarrier 本身非性能瓶颈，但用法不当会导致阻塞、资源浪费或死锁；关键在于避免 parties 失配、屏障动作耗时、状态残留，并考虑 phaser 等更灵活替代方案。
CyclicBarrier 本身不是性能瓶颈的源头，但用法不当会引发线程阻塞、资源浪费甚至死锁。关键不在“怎么用”，而在“什么时候不该用”和“怎么配得准”。
别让 parties 数量失配拖慢整个流程
parties 值必须严格匹配实际参与线程数。设为 4 却只启动 3 个线程，第 4 个永远等不到，所有线程卡在 await()；反过来，设为 3 却启动 5 个线程，多出的 2 个会立刻抛 BrokenBarrierException 并中断流程。
- 动态任务场景（比如区域数量随配置变化）：不要硬编码 parties，从配置或运行时参数读取后创建实例
- 线程池中复用 CyclicBarrier 时，确保每次调用前已 reset() 或确认上一轮已自然完成
- 上线前用单元测试覆盖边界情况：少一个线程、多一个线程、某个线程异常退出
避免在屏障动作里塞耗时操作
构造时传入的 Runnable（barrierAction）会在所有线程到达后、释放前执行。如果这里做数据库写入、远程调用或复杂计算，等于把所有线程堵在门口排队——它成了单点瓶颈。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 屏障动作只做轻量协调：记录日志、发信号、更新内存状态
- 重逻辑拆到 await() 之后：比如“汇总”动作放在 barrier.await() 返回后由某一线程单独执行
- 若必须异步处理，可在 barrierAction 中提交到独立线程池，不阻塞栅栏释放
警惕重复使用中的状态残留
CyclicBarrier 虽支持自动重置，但前提是上一轮没被破坏。任一线程 await() 时被中断、超时或抛出未捕获异常，屏障就会进入 broken 状态，后续所有 await() 都立即抛 BrokenBarrierException。
- 每个 await() 必须包裹 try-catch，且对 BrokenBarrierException 做明确处理（如重试或降级）
- 不要依赖“自动重置”就省略异常兜底——broken 状态不会自行恢复，需显式调用 reset()
- 高并发压测中建议加监控：通过 getNumberWaiting() 和 isBroken() 暴露指标，及时发现异常积压
比 CyclicBarrier 更灵活的替代选择
当需要动态增减参与者、分组等待或跨阶段复用时，CyclicBarrier 的固定 parties 就成了硬伤。
- Phaser 更适合动态场景：支持 arriveAndDeregister()、register()，无需重建对象
- CountDownLatch 用于单次主线程等待，代码更轻、开销更低
- CompletableFuture.allOf() + thenCombine() 可替代简单聚合，避免显式线程同步
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
