cyclicbarrier超时会立即破损，所有等待线程抛出brokenbarrierexception；恢复需显式reset（前提无线程在await），或更推荐每轮新建实例以避免状态污染。
超时等待本身不会直接损坏 CyclicBarrier，但一旦有线程因超时抛出 TimeoutException，屏障会立即进入破损（broken）状态，所有正在等待的线程都会被唤醒并抛出 BrokenBarrierException。恢复的关键不是“修复”旧屏障，而是正确处理破损、重置或重建。
超时触发后，屏障状态立刻变为破损
当任一线程调用 await(long, TimeUnit) 超时，CyclicBarrier 内部会执行 breakBarrier()，将 generation.broken = true，并唤醒所有等待线程。此时无论其他线程是否已到自身超时点，都**不再等待**，而是统一收到 BrokenBarrierException。
这意味着：你不能指望“等一等再继续”，必须在异常捕获逻辑中主动应对。
必须显式重置，且重置前需确认无残留等待
reset() 是唯一能将破损屏障恢复为可用状态的操作，但它有前提：
- 调用
reset()时，不能有线程仍在执行await()—— 否则这些线程会立即抛出BrokenBarrierException，造成二次异常 - 建议在所有参与线程都退出等待逻辑（如完成异常处理、退出循环）后再调用
reset() - 若使用线程池，注意任务可能复用线程，需确保每个任务对屏障的状态有明确控制权
更健壮的做法：按轮次新建屏障实例
比起复用和重置一个易破损的对象，推荐为每次协作周期创建新 CyclicBarrier 实例：
- 避免状态污染：上一轮的破损、中断、计数残留不会影响下一轮
- 天然解耦：每个屏障只服务于一次协作（例如一次 RPC 请求、一次批处理任务）
- 配合 barrierAction 使用，可统一做初始化或清理工作
例如，在性能压测中每轮并发请求开始前 new CyclicBarrier(n)，比全局共享一个对象更安全可靠。
异常处理不能只打印日志
捕获 BrokenBarrierException 或 TimeoutException 后，仅记录日志会导致任务静默失败或线程卡死：
- 若业务允许重试，可在 catch 块中加入退避逻辑（如
Thread.sleep(100)），然后重新进入 await 流程 - 若需终止当前协作，应同步通知其他参与者（如通过共享 volatile 标志或 CountDownLatch）
- 务必检查
isBroken()，并在必要时调用reset()或放弃本轮
