spring aop 的 @around 通知在目标方法抛出异常时若未妥善处理 try-finally 结构，会导致计时逻辑失效；本文详解根本原因并提供健壮、线程安全的执行时间监控方案。
spring aop 的 @around 通知在目标方法抛出异常时若未妥善处理 try-finally 结构，会导致计时逻辑失效；本文详解根本原因并提供健壮、线程安全的执行时间监控方案。
在使用 Spring AOP 对业务方法进行执行耗时监控时，一个常见却易被忽视的问题是：当被代理方法声明抛出受检异常（如 throws CustomerException），且实际执行中发生异常时，原有的 @Around 切面可能完全不触发后续的耗时记录逻辑。这并非 Pointcut 表达式失效，而是切面实现本身的控制流缺陷所致。
问题根源在于原始代码中将 proceedingJoinPoint.proceed() 放在 try 外部，并在 try 块中计算耗时——一旦 proceed() 抛出异常，程序立即跳出当前方法，endTime 和 metricsService.metricsTimer(...) 根本不会执行。即使该异常最终被上层捕获，AOP 层的监控逻辑也已中断。
✅ 正确做法是：将 proceed() 置于 try 块中，并把耗时上报逻辑统一移至 finally 块中执行。finally 保证无论方法正常返回还是抛出异常（包括受检/非受检异常），计时统计均能可靠执行：
@Pointcut("execution(* com.customer.service.ExecuteCustomerService.initiateExecuteCustomer(..))")
private void logExecuteCustomer() {}
@Around("logExecuteCustomer()")
public Object TimerMonitoring(ProceedingJoinPoint proceedingJoinPoint) throws Throwable {
long startTime = System.currentTimeMillis();
try {
return proceedingJoinPoint.proceed(); // 执行目标方法（可能抛异常）
} finally {
// ✅ 无论成功或失败，均在此统计耗时
long duration = System.currentTimeMillis() - startTime;
try {
MethodSignature signature = (MethodSignature) proceedingJoinPoint.getSignature();
String desc = signature.getDeclaringType().getSimpleName()
+ "." + signature.getName();
metricsService.metricsTimer(desc, duration);
} catch (Exception e) {
log.error("Failed to record metrics for {}", proceedingJoinPoint, e);
}
}
}? 进阶建议：
- 避免强依赖 MethodSignature：若仅需可读标识，直接使用 proceedingJoinPoint.toString() 更简洁、安全（无需类型转换，规避 ClassCastException 风险）；
- 考虑使用 StopWatch 或 Micrometer Timer：对高并发场景，System.currentTimeMillis() 精度与性能不如 System.nanoTime()；推荐封装为 StopWatch 或集成 Micrometer 的 Timer.record()；
- 注意异常传播行为：@Around 中 proceed() 抛出的异常会原样向上抛出，无需额外 throw —— 保持原有异常语义，确保事务、重试等机制不受影响。
总结：AOP 计时切面的核心契约是「可观测性不因业务异常而丢失」。通过 try...finally 结构保障监控逻辑的强制执行，是编写健壮切面的基本原则。务必避免在 finally 外进行关键副作用操作，尤其涉及指标采集、日志记录或资源清理等场景。
