该用 CyclicBarrier 而不是 CountDownLatch 时：需线程组多次协同到达同一屏障点并一起继续执行，且要求可重用；CountDownLatch 仅适用于一次性等待操作完成。
什么时候该用 CyclicBarrier 而不是 CountDownLatch
核心区别在「可重用性」和「等待触发点」：CyclicBarrier 是一组线程互相等待彼此到达某个点后**一起继续执行**，且能重复使用；CountDownLatch 是一个或多个线程等待**其他线程完成一系列操作**，计数归零后不可重置。
常见错误现象：用 CountDownLatch 做多轮协同（比如每轮 5 个线程同步开始），结果第二轮调用 await() 直接返回——因为 latch 已经被触发过，无法重用。
- 适合
CyclicBarrier的场景：并行分段计算后汇总、模拟并发压测（所有线程同时发起请求）、多阶段流水线中各阶段需对齐进度 - 适合
CountDownLatch的场景：主线程等子任务全部结束、初始化完成后再启动服务 -
CyclicBarrier构造时可传入Runnable，在所有线程到达后、释放前由**最后一个到达的线程**执行一次（常用于汇总逻辑）
CyclicBarrier.await() 的阻塞与中断处理
调用 await() 会阻塞当前线程，直到所有参与线程都调用了它，或发生中断/超时。这点和 Lock.lockInterruptibly() 类似——它响应中断，但不静默吞掉。
常见错误现象：没捕获 InterruptedException，导致线程中断信号丢失，后续逻辑仍执行；或捕获后没恢复中断状态（Thread.currentThread().interrupt()），影响上层调度。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 必须显式处理
InterruptedException，否则编译不通过（它是 checked exception） - 如果不想立即退出，可在 catch 块里调用
Thread.currentThread().interrupt()恢复中断标记 - 带超时的
await(long, TimeUnit)会抛出TimeoutException，此时 barrier 仍处于 broken 状态，后续调用直接抛BrokenBarrierException
屏障损坏（BrokenBarrierException）怎么发生的
CyclicBarrier 很脆弱：任一参与线程在 await() 期间被中断、超时、或抛出未捕获异常，整个 barrier 就会进入 broken 状态，后续所有 await() 都立刻抛 BrokenBarrierException。
这不是 bug，是设计使然——避免部分线程卡死或状态不一致。但容易被忽略的是：broken 状态**不会自动恢复**，必须手动调用 reset()（会唤醒所有等待线程并清空状态）。
- 不要依赖
reset()来“修复”逻辑错误，它只是重置状态，不解决根本原因 - 若 barrier 被频繁打破，说明协作逻辑有缺陷（比如某线程总因异常提前退出）
-
isBroken()可用于检查当前状态，但注意它只反映“是否 broken”，不提供原因
性能与线程安全注意事项
CyclicBarrier 内部用 ReentrantLock + Condition 实现，本身是线程安全的，但它的回调 Runnable 和参与线程共享的数据**不是自动线程安全的**。
常见错误现象：多个线程在 barrier 回调里往同一个 ArrayList 添加数据，结果漏写或 ConcurrentModificationException。
- 回调
Runnable由最后一个到达的线程执行，它看到的共享变量是“最新写入”的，但不保证其他线程已刷新到主内存（需volatile或同步机制） - 避免在回调里做耗时操作（如 I/O、远程调用），否则会拖慢所有等待线程的释放
- 构造时指定的 parties 数必须和实际调用
await()的线程数严格匹配；少调用一次，其余线程永远阻塞
