CyclicBarrier异常需在业务方法中抛出才能被AspectJ切面捕获；切面应区分BrokenBarrierException、InterruptedException、TimeoutException语义处理，禁止修改屏障状态，仅负责可观测性。
在Java中使用CyclicBarrier配合AspectJ切面时，异常捕获与通知的关键在于：**切面不能直接拦截CyclicBarrier.await()抛出的中断或超时异常（如InterruptedException、BrokenBarrierException、TimeoutException），除非这些异常实际传播到了被切点（pointcut）所匹配的方法体内部**。
切点设计必须覆盖异常实际抛出处
CyclicBarrier.await()本身是同步阻塞调用，其异常由调用线程在执行该方法时直接抛出。若你在业务方法A中调用await()，而AspectJ切点定义为@Around("execution(* com.example.service.*.*(..))")，则只有当异常从方法A体内向外传播时，环绕通知才能捕获到它。
- ✅ 正确：方法A调用
await()后未捕获异常，让异常向上抛出 → 切面可拦截 - ❌ 错误：方法A内用
try-catch吞掉BrokenBarrierException且未重新抛出 → 切面无法感知该异常 - ⚠️ 注意：
InterruptedException属于受检异常，必须显式处理；若被catch并恢复中断状态（Thread.currentThread().interrupt()），但未再抛出，切面也收不到
环绕通知中需区分异常类型并保留语义
在@Around通知中，应避免统一catch (Throwable t)后简单记录日志或返回默认值，否则会掩盖CyclicBarrier的协作失败语义（如屏障被破坏、线程被中断）。
- 对
BrokenBarrierException：说明至少有一个线程在等待时异常退出，整个屏障已失效，后续await()调用都会立即抛此异常；建议记录“Barrier broken by thread: ”+t.getLocalizedMessage()，并考虑触发重置逻辑（如barrier.reset()） - 对
InterruptedException：反映当前线程被外部中断，应优先恢复中断状态（Thread.currentThread().interrupt()），再决定是否继续传播或封装为业务异常 - 对
TimeoutException（需配合await(long, TimeUnit)）：属于正常控制流分支，可转为自定义超时异常（如BarrierTimeoutException），便于上层分类处理
避免在切面中修改屏障状态
切面是横切关注点，不应承担协调职责。不要在通知中主动调用barrier.reset()或barrier.getNumberWaiting()等操作。
立即学习“Java免费学习笔记（深入）”；
- 原因：屏障实例通常被多个线程共享，切面执行上下文不确定是哪个线程触发的，重置可能干扰其他正在等待的线程
- 正确做法：将屏障管理逻辑（如故障恢复、重试、重置）封装进业务服务类，由具体业务策略决定何时重置；切面只负责可观测性（记录、告警、指标上报）
- 若需监控等待线程数，可用
@Before切点 +proceedingJoinPoint.getArgs()提取传入的CyclicBarrier参数，再调用getNumberWaiting()读取，但仅用于日志或Meter记录
结合Spring AOP时注意代理模式限制
若使用Spring AOP（基于AspectJ注解但运行在Spring代理机制下），需确认目标对象是否被CGLIB或JDK动态代理正确包裹：
- 接口代理（JDK）：只能拦截通过接口调用的
await()，若业务方法是package-private或private，切点不生效 - CGLIB代理：支持非接口方法，但要求目标类不能是
final，方法也不能是final或static - 推荐：将
CyclicBarrier相关协调逻辑抽成独立service类，并确保其Bean由Spring管理、方法为public，以保障切点稳定命中
