本文探讨了在Spring Boot应用中，当异常被全局`ExceptionHandler`捕获时，如何有效记录方法执行时间的问题。文章介绍了两种主要策略：一是利用Spring AOP在方法执行前后环绕，实现统一的执行时间测量和异常捕获；二是通过自定义异常类，在业务逻辑层捕获异常并封装执行时间，再由`ExceptionHandler`进行处理。这两种方法各有优势，可根据项目需求选择，旨在提供清晰、可维护的解决方案。
在开发基于Spring Boot的应用程序时，我们经常需要监控方法的执行时间，特别是在出现异常的情况下，了解异常发生时的耗时对于性能分析和问题排查至关重要。然而，当应用程序使用全局@ExceptionHandler来统一处理异常时，直接在业务方法内部捕获异常并记录时间，会使得代码变得冗余。本文将介绍两种在ExceptionHandler被调用时也能记录方法执行时间的专业方法。
方法一：利用Spring AOP实现执行时间测量与异常处理
Spring AOP（面向切面编程）提供了一种优雅的方式来处理横切关注点，如日志记录、性能监控和事务管理。通过定义一个切面，我们可以在不修改业务逻辑代码的情况下，在特定方法的执行前后插入逻辑。
1. 定义一个切面类
首先，创建一个切面类，使用@Aspect和@Component注解，使其成为Spring管理的Bean。
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.stereotype.Component;
import java.time.Duration;
import java.time.Instant;
@Aspect
@Component
public class ExecutionTimeAspect {
private static final Logger logger = LoggerFactory.getLogger(ExecutionTimeAspect.class);
/**
* 定义一个切点，匹配所有在com.example.app.service包及其子包下的公共方法
* 实际应用中可根据需求调整切点表达式
*/
@Around("execution(public * com.example.app.service.*.*(..))")
public Object logExecutionTimeAndHandleException(ProceedingJoinPoint joinPoint) throws Throwable {
Instant start = Instant.now();
Object result;
try {
// 执行目标方法
result = joinPoint.proceed();
} catch (Exception e) {
Instant end = Instant.now();
long executionTimeMillis = Duration.between(start, end).toMillis();
logger.error("方法 {} 执行异常，耗时 {} ms. 异常信息: {}",
joinPoint.getSignature().toShortString(),
executionTimeMillis,
e.getMessage(),
e);
// 重新抛出异常，以便ExceptionHandler能够捕获
throw e;
} finally {
// 无论是否发生异常，都会执行此处的逻辑
// 如果没有异常，在这里记录成功执行的时间
if (result != null) { // 简单判断，实际可能需要更复杂的逻辑
Instant end = Instant.now();
long executionTimeMillis = Duration.between(start, end).toMillis();
logger.info("方法 {} 成功执行，耗时 {} ms.",
joinPoint.getSignature().toShortString(),
executionTimeMillis);
}
}
return result;
}
}2. 配置说明
- @Aspect: 声明这是一个切面。
- @Component: 将此切面注册为Spring Bean。
- @Around: 定义一个环绕通知。它包裹了目标方法的执行，允许在方法调用前后执行自定义逻辑。
- ProceedingJoinPoint: 在环绕通知中，通过调用joinPoint.proceed()来执行目标方法。
- 切点表达式: execution(public * com.example.app.service.*.*(..)) 这是一个典型的切点表达式，表示匹配com.example.app.service包下所有公共方法。你需要根据自己的项目结构调整这个表达式。
- 异常处理: 在try-catch块中，我们捕获了目标方法抛出的任何异常。在catch块中，可以记录异常信息和执行时间，然后必须重新抛出异常 (throw e;)，这样全局的ExceptionHandler才能继续捕获并处理它。
- 时间记录: Instant.now()和Duration.between()用于精确测量方法的执行时间。
3. 优势与考量
- 代码解耦: 将时间测量和异常日志逻辑从业务代码中分离，提高了代码的可读性和可维护性。
- 统一管理: 可以在一个地方管理所有指定方法的性能监控和异常日志。
- 灵活性: 切点表达式可以非常灵活地定义，精确控制哪些方法受AOP影响。
方法二：结合自定义异常传递执行时间
如果AOP对于你的特定场景过于宽泛，或者你希望在业务逻辑层更精细地控制异常信息和执行时间的传递，可以考虑使用自定义异常类来封装执行时间。
1. 定义自定义异常类
创建一个继承自RuntimeException的自定义异常类，包含一个字段来存储执行时间。
import java.time.Duration;
public class TimeMeasuredException extends RuntimeException {
private final Duration executionTime;
private final Throwable originalCause; // 用于存储原始异常
public TimeMeasuredException(Duration executionTime, Throwable originalCause) {
super("方法执行异常，耗时 " + executionTime.toMillis() + " ms", originalCause);
this.executionTime = executionTime;
this.originalCause = originalCause;
}
public Duration getExecutionTime() {
return executionTime;
}
public Throwable getOriginalCause() {
return originalCause;
}
}2. 修改业务逻辑层
在可能抛出异常的业务方法中，使用try-catch块来捕获原始异常，并将其包装进TimeMeasuredException，同时记录执行时间。
import org.springframework.stereotype.Service;
import java.time.Duration;
import java.time.Instant;
@Service
public class MyBusinessService {
public String performComplexOperation() {
Instant start = Instant.now();
try {
// 模拟一些复杂的业务逻辑，可能抛出异常
if (Math.random() > 0.5) {
throw new IllegalArgumentException("随机参数错误！");
}
Thread.sleep(200); // 模拟耗时操作
return "操作成功完成";
} catch (Exception ex) {
Instant end = Instant.now();
Duration executionTime = Duration.between(start, end);
// 捕获原始异常，并抛出自定义的TimeMeasuredException
throw new TimeMeasuredException(executionTime, ex);
}
}
}3. 修改全局异常处理器
在全局@RestControllerAdvice或@ControllerAdvice中，捕获TimeMeasuredException，然后从中提取执行时间和原始异常信息进行处理。
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.http.HttpStatus;
import org.springframework.http.ResponseEntity;
import org.springframework.web.bind.annotation.ExceptionHandler;
import org.springframework.web.bind.annotation.RestControllerAdvice;
@RestControllerAdvice
public class GlobalExceptionHandler {
private static final Logger logger = LoggerFactory.getLogger(GlobalExceptionHandler.class);
@ExceptionHandler(TimeMeasuredException.class)
public ResponseEntity handleTimeMeasuredException(TimeMeasuredException ex) {
// 从自定义异常中获取执行时间
long executionTimeMillis = ex.getExecutionTime().toMillis();
// 获取原始异常
Throwable originalCause = ex.getOriginalCause();
logger.error("请求处理异常，耗时 {} ms. 原始异常类型: {}, 消息: {}",
executionTimeMillis,
originalCause.getClass().getSimpleName(),
originalCause.getMessage(),
originalCause);
ErrorResponse errorResponse = new ErrorResponse(
HttpStatus.INTERNAL_SERVER_ERROR.value(),
"处理请求失败: " + originalCause.getMessage(),
executionTimeMillis + " ms"
);
return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
}
// 也可以捕获所有Exception，然后检查是否是TimeMeasuredException的实例
@ExceptionHandler(Exception.class)
public ResponseEntity handleGenericException(Exception e) {
if (e instanceof TimeMeasuredException) {
return handleTimeMeasuredException((TimeMeasuredException) e);
}
// 处理其他未被TimeMeasuredException包装的通用异常
logger.error("发生未知异常: {}", e.getMessage(), e);
ErrorResponse errorResponse = new ErrorResponse(
HttpStatus.INTERNAL_SERVER_ERROR.value(),
"服务器内部错误",
"未知"
);
return new ResponseEntity<>(errorResponse, HttpStatus.INTERNAL_SERVER_ERROR);
}
// 辅助类用于构建统一的错误响应
static class ErrorResponse {
public int status;
public String message;
public String executionTime;
public ErrorResponse(int status, String message, String executionTime) {
this.status = status;
this.message = message;
this.executionTime = executionTime;
}
}
} 4. 优势与考量
- 精确控制: 可以在每个需要监控的业务方法中精确地决定何时开始计时、何时结束计时，以及如何封装异常。
- 明确意图: 自定义异常TimeMeasuredException明确地表明了该异常携带了执行时间信息。
- 侵入性: 相对于AOP，这种方法对业务逻辑代码有一定的侵入性，需要在每个相关方法中添加try-catch块。
总结与选择
两种方法都能够实现在ExceptionHandler被调用时记录方法执行时间的需求，但适用场景略有不同：
-
选择Spring AOP：
- 当你需要对大量方法进行统一的性能监控和异常日志记录，并且这些方法具有相似的特征（如都在某个包下、都属于某个接口实现）。
- 当你希望将横切关注点与业务逻辑彻底解耦。
- 当你想减少重复的try-catch块代码。
-
选择自定义异常：
- 当你只需要对少数特定方法进行精细的执行时间测量，并希望在异常处理时明确地传递这些信息。
- 当AOP的配置对你来说过于复杂，或者你更倾向于在代码中显式地控制异常流程和数据封装。
- 当除了执行时间，你还需要在异常中携带其他业务相关的上下文信息时，自定义异常类提供了更大的灵活性。
在实际项目中，可以根据团队的技术栈、项目规模和具体需求来选择最合适的方案。通常，对于广泛的性能监控，AOP是更推荐的选择；而对于特定业务场景下需要携带额外异常信息的，自定义异常则更为直观。无论选择哪种方式，目的都是为了提高代码的可维护性、可观测性，并为问题诊断提供更多有价值的数据。
