MyBatis-Plus项目启动缓慢问题分析与解决方案

问题现象

在使用MyBatis-Plus 3.5.7版本的项目中，开发者遇到了项目启动异常缓慢的问题。通过日志分析发现，所有Mapper接口在启动时被加载了两次，且第二次加载耗时异常，每个Mapper接口的初始化时间达到了1-2秒不等。

问题排查过程

通过BeanPostProcessor记录的日志显示，每个Mapper接口都经历了两次初始化：

1. 第一次初始化耗时极短（1-2毫秒）
2. 第二次初始化耗时异常（1200-2500毫秒）

这种重复加载且耗时异常的现象明显不正常。经过开发者逐步排查，最终发现问题与项目中一个自定义的AOP切面类有关。

根本原因分析

导致MyBatis-Plus启动缓慢的根本原因是项目中定义的一个日志记录切面(LogAspect)与MyBatis-Plus的Mapper代理机制产生了某种冲突或性能瓶颈。具体表现为：

1. 切面定义过于宽泛：切面的切入点表达式execution (public * com.dm.api.*.*.*(..))匹配范围过大，可能意外拦截了MyBatis-Plus内部的一些关键操作。

2. 切面处理逻辑复杂：该切面在before advice中执行了大量操作，包括获取安全上下文、HTTP请求信息、参数处理等，这些操作在Mapper初始化阶段可能不必要地被执行。

3. 线程本地变量使用：切面中使用了ThreadLocal来存储日志信息，可能在Mapper初始化阶段产生了额外的开销。

解决方案

针对这个问题，可以采取以下几种解决方案：

1. 优化切面定义

缩小切入点表达式的匹配范围，避免拦截MyBatis-Plus内部操作：

@Pointcut("execution(public * com.dm.api..service..*(..)) || 
          execution(public * com.dm.api..controller..*(..))")
public void logAspect() {}

2. 添加排除规则

在切面中添加对Mapper接口的排除规则：

@Pointcut("execution(public * com.dm.api..*(..)) && 
          !within(com.baomidou.mybatisplus.core.mapper..*)")
public void logAspect() {}

3. 延迟切面初始化

通过实现SmartInstantiationAwareBeanPostProcessor接口，确保切面在Mapper初始化完成后再进行初始化。

4. 简化切面逻辑

优化切面中的before advice逻辑，减少不必要的操作：

@Before("logAspect() && @annotation(log)")
public void doBefore(JoinPoint joinPoint, Log log) {
    // 简化参数处理逻辑
    // 移除不必要的安全上下文和请求处理
}

最佳实践建议

1. 精确控制AOP切入点：在使用AOP时，应该尽可能精确地定义切入点，避免拦截框架内部的操作。

2. 性能敏感操作后置处理：对于日志记录这类非关键路径的操作，可以考虑使用异步处理或后置处理，避免影响主要业务流程。

3. 定期性能测试：在引入新的框架或组件后，应该进行启动时间和运行时性能的基准测试。

4. 理解框架初始化机制：深入理解MyBatis-Plus等ORM框架的初始化过程，避免与其关键生命周期阶段产生冲突。

总结

MyBatis-Plus项目启动缓慢的问题往往源于框架初始化过程与其他组件（特别是AOP）的交互问题。通过精确控制AOP切入点、优化切面逻辑、合理安排组件初始化顺序等手段，可以有效解决这类性能问题。这也提醒我们在使用复杂框架时，需要全面考虑各组件之间的相互影响，才能构建出高性能、稳定的应用系统。