cyclicbarrier异常处理分三类：runtimeexception导致屏障破损并抛brokenbarrierexception；interruptedexception仅中断当前线程且不破损屏障；brokenbarrierexception表示屏障已破损需reset恢复。
当线程在 CyclicBarrier 的屏障点（即调用 await()）处抛出异常，处理方式取决于异常类型：普通异常（如 RuntimeException）会直接由该线程抛出；而中断（InterruptedException）或屏障被破坏（BrokenBarrierException）则会终止当前等待，并影响其他等待线程。
运行时异常（RuntimeException）的传播
如果某个线程在到达屏障前、或在 barrierAction（可选的屏障触发任务）中抛出未捕获的 RuntimeException，该异常会原样抛出给调用方，且 CyclicBarrier 会被自动标记为“破损”（broken）。此时其他正在等待或后续调用 await() 的线程，将立即收到 BrokenBarrierException，不再继续等待。
- barrierAction 中抛异常 → barrier 立即 broken：即使只有一个线程执行失败，整个屏障失效
- 非 barrierAction 的 await() 调用中抛 RuntimeException（如空指针）→ 同样导致 broken
- 一旦 broken，必须调用
reset()才能复用，否则所有 await() 都快速失败
InterruptedException 和 BrokenBarrierException 的区别
await() 声明抛出两种受检异常：InterruptedException 和 BrokenBarrierException。它们触发条件和影响不同：
-
InterruptedException：当前线程在等待时被中断（
Thread.interrupt()），屏障本身不 broken，其他线程可继续等待；但该线程提前退出，需自行处理中断状态 -
BrokenBarrierException：表示屏障已处于破损状态（因之前某线程异常、调用
reset()或超时失败），所有等待线程都会收到此异常，无法继续同步 - 二者不会同时发生；若等待中被中断，抛
InterruptedException；若屏障已 broken，抛BrokenBarrierException
如何安全地处理屏障点异常
关键是在每个线程的 await() 调用处做好异常捕获与恢复逻辑，尤其关注屏障是否仍可用：
- 始终用 try-catch 包裹
await()，分别处理InterruptedException、BrokenBarrierException和运行时异常 - 捕获
BrokenBarrierException后，通常应放弃本次协作任务，或主动调用reset()（注意：仅一个线程 reset 即可，多线程调用无害但冗余） - 若业务允许重试，可在 catch 块中加延迟后重新 await（但需确认 barrier 是否已 reset）
- 避免在
barrierAction中执行不可靠操作；如必须，应在内部 try-catch 并记录日志，防止意外破损屏障
reset() 的作用与注意事项
reset() 用于强行恢复屏障到初始状态，使它可再次使用。但它有副作用：
- 调用
reset()会唤醒所有正在等待的线程，并让它们的await()抛出BrokenBarrierException - reset 后，计数器重置为构造时指定的 parties 数，但 barrierAction 不会重新初始化（仍是原引用）
- 无需同步调用 reset —— 它是线程安全的，但应确保重置时机合理（例如在所有线程都已退出或明确放弃后）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
