前阵子有个朋友找我调一个Spring MVC老项目的Bug现象是接口偶尔返回慢但代码里找不到任何耗时操作。后来发现日志散落得到处都是几百个Controller方法里有打印入参的、有记耗时的、有拼操作日志的逻辑都是同一套只是复制的次数太多风格已经走样了。我给他开的药方很简单把AOP用起来。Spring MVC项目里AOP这个东西常常被讲得很玄乎什么面向切面编程、什么横切关注点听起来像论文术语实际上它就是帮你把每个方法都要干的重复事情抽出来集中处理然后让业务代码变干净。这篇文章不绕弯子直接讲清楚三件事AOP在Spring MVC里到底能干哪些实事、传统XML配置和注解配置分别怎么写、以及配置完之后最常踩的坑怎么排查。适合那些被重复代码折磨过、或者给Service层加切面却发现完全没生效的Java开发者。1. 为什么Spring MVC项目离不开AOP1.1 日志、权限、性能监控那些四处粘贴的样板代码接触过真实业务系统的都知道一个Controller方法的标准开场白往往是这样的PostMapping(/order/create) public Result createOrder(RequestBody OrderDTO dto) { log.info(创建订单入参{}, JSON.toJSONString(dto)); long start System.currentTimeMillis(); try { // 权限校验 if (!checkPermission(getCurrentUserId())) { return Result.fail(403, 无权限); } // 业务逻辑 Order order orderService.create(dto); log.info(创建订单成功耗时{}ms, System.currentTimeMillis() - start); return Result.success(order); } catch (Exception e) { log.error(创建订单异常参数{}, JSON.toJSONString(dto), e); return Result.fail(500, 系统繁忙); } }这段代码有毛病吗单看没问题。但如果你有50个类似的接口这50个接口里就塞了50份日志打印、50份手动计时、50份权限校验。更要命的是有一天产品说要统一日志格式把入参改成请求参数你得全局搜索替换50个位置漏掉一个线上日志就花式出问题。AOP解决的就是这种横切关注点。它把这些重复动作定义成一个切面在方法执行前、执行后、抛异常时自动插入逻辑业务方法本身不再关心这些事。打个不太严谨的比方你家小区原来每户都要自己下楼扔垃圾现在物业在每个楼层设了一个垃圾口你只需要把垃圾放进管道物业统一处理。这个管道就是AOP的通知机制。1.2 哪些场景适合用AOP哪些场景千万别硬上根据我在实际项目里的经验AOP最适用的场景有几类请求日志与操作审计记录谁在什么时间调用了什么接口入参出参是什么改了什么数据。这是最常见的AOP用途。权限与参数校验统一的登录状态校验、接口级权限判断在切面里做前置检查。性能监控与耗时统计给接口或Service方法统一计算耗时超过阈值就告警。异常兜底处理统一捕获异常、转换错误码避免每个方法手写try-catch。事务管理Spring的Transactional本质就是AOP的应用只是框架帮你封装好了。缓存处理某些查询方法的缓存读取和回填用切面可以做到不改业务代码就加上缓存。但有两类场景我的建议是不要硬上AOP第一类是业务规则高度个性化的场景。比如订单状态流转每个状态下的处理逻辑差异极大你没法用一段通用逻辑统一切入硬写的话切面里全是if-else反而把代码搞得更乱。第二类是超高频且对耗时极度敏感的方法。AOP本质是代理调用会在方法调用链上多一层拦截。绝大多数业务系统里这层拦截的耗时可以忽略不计但如果是一个每秒被调用几十万次的纯内存计算多一次代理分派、多一次切点判断积累起来也是可感知的性能开销。碰到这种代码别用AOP老老实实写清楚。2. Spring MVC里AOP的代理原理与双容器问题2.1 JDK动态代理与CGLIB的取舍要搞懂AOP在Spring MVC里的行为先得明白Spring AOP的实现根基动态代理。Spring AOP不是在编译期把切面代码织入到业务类里的它是在运行时生成一个代理对象把这个代理对象放进Spring容器业务代码拿到的其实是代理对象的引用。Spring生成代理有两种方式JDK动态代理要求目标对象必须实现接口。它基于接口生成一个Proxy对象只能代理接口中声明的方法。CGLIB不要求实现接口它生成目标类的子类在子类里重写目标方法以此实现代理。这两种方式各有什么坑我用一张表说清楚对比项JDK动态代理CGLIB目标要求必须实现接口不需要接口生成机制基于接口生成Proxy对象基于继承生成子类方法限制只能拦截接口中声明的方法不能被final修饰性能创建代理快调用较慢创建代理慢调用较快默认选择Spring默认优先当无接口或指定proxyTargetClass时使用Spring的默认策略是目标类有接口就走JDK动态代理没有接口才走CGLIB。如果你在配置里声明了aop:aspectj-autoproxy proxy-target-classtrue/或者Spring Boot里设置了spring.aop.proxy-target-classtrue那就会强制走CGLIB。在新版本的Spring Boot里CGLIB已经是默认选项因为大多情况下不需要目标实现接口出错概率更低。2.2 根容器和子容器为什么切面在Controller层好使、在Service层失效这可能是Spring MVC中AOP最隐蔽的一个坑比任何切点表达式都令人头疼。传统Spring MVC项目通常有两个Spring容器根容器由ContextLoaderListener创建的ApplicationContext通常加载applicationContext.xml负责管理Service、DAO、数据源等业务层和基础设施层的Bean。子容器由DispatcherServlet创建的WebApplicationContext通常加载spring-mvc.xml负责管理Controller、HandlerMapping等Web层组件。子容器能看到根容器里的Bean但根容器看不到子容器里的Bean。引用关系是单向的。这个机制对AOP配置有什么影响我举一个亲历的例子。某个项目里我把切面类写在了spring-mvc.xml的组件扫描路径下aop:aspectj-autoproxy/也在spring-mvc.xml里开启了。结果Controller层的切面一切正常Service层的切面怎么都不生效。原因说穿了很简单切面注册在子容器而Service Bean在根容器。哪怕切点表达式匹配到了Service的方法子容器里的代理机制管不到根容器里的Bean——它只对子容器自己管理的Bean生效。反过来如果切面配置在根容器里对根容器管理的Service生效但Controller在子容器里又不在管辖范围内。所以传统Spring MVC项目里配置AOP最基本的一条经验是要对哪一层的Bean做切面切面就必须和那一层Bean在同一个容器里。我的习惯是像日志、权限、异常处理这类需要同时覆盖Controller和Service的切面统一配置在根容器的applicationContext.xml里保证两边都能命中。如果只做Web层的拦截比如记录接口入参出参那放在spring-mvc.xml也没问题。Spring Boot项目没有这种双容器结构基本一个容器管所有所以这个坑在Spring Boot里几乎遇不到。这也是很多从Boot转回MVC项目的同学一脸懵的原因。2.3 切点表达式怎么写才能精准命中切点决定切面作用于哪些方法。表达式写错了要么切不到任何方法要么切到一大片不该切的对象引发各种诡异问题。常用的execution表达式格式是execution(修饰符 返回类型 包路径.类名.方法名(参数))几个我在项目里常用的写法execution(public * com.example.controller.*.*(..))拦截com.example.controller包下所有Controller类的所有public方法参数任意。execution(* com.example.service.impl.*.*(..))拦截service.impl包下所有类的所有方法。execution(* com.example..*.*(..))双点号表示包及子包递归匹配全包扫描慎用范围太大。annotation(com.example.annotation.OperLog)切到所有标注了OperLog注解的方法这种搭配自定义注解的方式在日志审计场景里极其好用。within(com.example.controller..*)按类型匹配匹配包内所有类的所有方法。写切点表达式时最需要注重的不是能不能匹配上而是会不会误匹配。比如上面说的com.example..*.*(..)这种写法会把Spring内部的一些Bean也扫进去某些类还没初始化完就被代理触发可能抛出意想不到的异常。我个人的习惯是先精确到包再按需放宽不要一开始就图省事写大范围。3. 从零配置一个Controller层请求日志切面3.1 传统Spring MVC的XML配置传统SSM结构的Spring MVC项目如果还没有引入AOP相关依赖第一步要先把Maven依赖加上。我一般是这样配的dependency groupIdorg.springframework/groupId artifactIdspring-aop/artifactId version5.3.29/version /dependency dependency groupIdorg.springframework/groupId artifactIdspring-aspects/artifactId version5.3.29/version /dependency dependency groupIdorg.aspectj/groupId artifactIdaspectjweaver/artifactId version1.9.19/version /dependency三个依赖各管一摊spring-aop提供AOP基础支持spring-aspects提供注解驱动的Aspect支持aspectjweaver提供切点表达式解析。缺了aspectjweaverexecution表达式解析就会出问题切面直接不生效。然后是配置文件。假设要在根容器里启用注解式AOPapplicationContext.xml需要这样写?xml version1.0 encodingUTF-8? beans xmlnshttp://www.springframework.org/schema/beans xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xmlns:aophttp://www.springframework.org/schema/aop xmlns:contexthttp://www.springframework.org/schema/context xsi:schemaLocationhttp://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop.xsd http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd !-- 手动开启Aspect注解支持 -- aop:aspectj-autoproxy proxy-target-classtrue/ !-- 切面类交给Spring管理 -- bean idrequestLogAspect classcom.example.aspect.RequestLogAspect/ /beans如果你更喜欢纯XML声明切面而不写Java注解类也可以用aop:config标签aop:config proxy-target-classtrue aop:aspect idwebLogAspect refrequestLogAspect aop:pointcut idcontrollerPointcut expressionexecution(* com.example.controller.*.*(..))/ aop:around methodaround pointcut-refcontrollerPointcut/ /aop:aspect /aop:config这种方式要求RequestLogAspect类里有一个名为around的方法方法签名是Object around(ProceedingJoinPoint pjp)。XML配置的好处是切点和切面完全外部化但缺点是改起来不够灵活注解方式才是现在的主流下面重点讲。3.2 基于Aspect注解的全套代码用注解驱动先确保配置里开启了aop:aspectj-autoproxy/然后写切面类。Component Aspect public class RequestLogAspect { private static final Logger log LoggerFactory.getLogger(RequestLogAspect.class); // 定义切点匹配controller包下所有类的所有方法 Pointcut(execution(* com.example.controller.*.*(..))) public void controllerPointcut() { } // Before方法执行前 Before(controllerPointcut()) public void before(JoinPoint joinPoint) { String methodName joinPoint.getSignature().getName(); Object[] args joinPoint.getArgs(); log.info(请求开始方法{}入参{}, methodName, JSON.toJSONString(args)); } // AfterReturning正常返回 AfterReturning(pointcut controllerPointcut(), returning result) public void afterReturning(JoinPoint joinPoint, Object result) { log.info(请求结束方法{}响应{}, joinPoint.getSignature().getName(), JSON.toJSONString(result)); } // Around最灵活的全包围 Around(controllerPointcut()) public Object around(ProceedingJoinPoint joinPoint) throws Throwable { long start System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); return result; } finally { long cost System.currentTimeMillis() - start; log.info(方法 {} 耗时{}ms, joinPoint.getSignature().toShortString(), cost); } } }几个容易混淆的点Before、AfterReturning、Around都是通知注解它们可以同时存在于一个切面类里Spring按配置顺序织入。AfterReturning有一个returning属性它把目标方法的返回值绑定通知方法的入参这样通知里才能拿到返回值。注意returning的对象类型不能写宽了否则Spring会跳过匹配。不想依赖返回值的场景直接写AfterReturning(controllerPointcut())方法不声明returning参数即可。切面类上加Component是为了让Spring把它当Bean管理加Aspect是告诉Spring这个类里有切面逻辑两个注解缺一不可。Spring Boot项目里也是一样的用法。3.3 简化Spring Boot下的三步启用如果你用的是Spring Boot整个流程会被压缩到极其简单。Spring Boot自带了一个AopAutoConfiguration只要类路径下存在org.aspectj.lang.annotation.Aspect它就自动开启EnableAspectJAutoProxy连配置都省了。第一步引入依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-aop/artifactId /dependency第二步写一个和上面一模一样的切面类加Component和Aspect。第三步确认启动类或配置类没有被手动作弊操作——如果有人手动设置了spring.aop.autofalse那就需要自己加EnableAspectJAutoProxy。如果你想强制走CGLIB代理在application.yml里写一行spring: aop: proxy-target-class: true新版本的Spring Boot默认本来就是proxy-target-classtrue所以这一行大多数时候不用写。4. 切面不生效我梳理过的高频排查链路4.1 自查清单从依赖到切点一份全过AOP最大的痛点不是写而是写了没反应。我整理了一份排查清单按照这个顺序从外到内查基本都能定位第一确认依赖。如果连aspectjweaver都没有切面类上的注解根本不会被解析。去mvn dependency:tree里看一眼确认有没有org.aspectj:aspectjweaver和org.springframework:spring-aop。第二确认自动代理是否开启。XML项目查aop:aspectj-autoproxy/Boot项目查spring.aop.auto是否被改成了false。没有这个开关你写的Aspect类只是一个普通Bean不产生任何拦截动作。第三确认切面类被Spring扫描到。切面类必须是一个注册过的Bean。查一下Component有没有加、包扫描路径是否覆盖了切面类所在的包。有个很隐蔽的情况切面类放在某个子包里但ComponentScan只扫描了Controller包切面类根本没进Spring容器那自然是静悄悄的。第四确认目标Bean所在容器和切面Bean所在容器一致。Spring MVC双容器的问题前面提到过这里不再重复但排查的时候一定要想一遍。我最常见的场景就是同事把切面和Controller放在同一个spring-mvc.xml里又说Service层切面不生效。第五确认切点表达式。把切点表达式复制出来手动写个测试方法往里套一遍看是否匹配。一个很实用的临时调试手段在切面通知的入口直接加一行System.out.println(aspect exec)如果能看到这行输出说明切点已经命中了目标问题大概率在后面的逻辑里。4.2 内部调用与public方法限制最容易被忽视的两个边界排查清单解决的是切面根本没启用的问题但有一些场景是切面启用正常、特定方法却没被切到。最经典的内部调用问题看这段代码Service public class UserServiceImpl implements UserService { public User getUser(String id) { // 业务逻辑 return queryFromDb(id); } public User getUserWithDetail(String id) { // 这里通过this调用不会走AOP代理 User user this.getUser(id); // 其他逻辑 return user; } }假设你的切点表达式配的是execution(* com.example.service..*.*(..))理论上getUserWithDetail和getUser都会走到代理。但实际执行时getUserWithDetail里通过this.getUser(id)调用的是目标对象自己的方法不是代理对象的方法。因为Spring容器里注入的Bean是被代理后的对象但this指向的是代理内部那个原始对象。结果就是其他类调getUser会被拦截而同类内部调getUser永远绕过了切面。解决方式有几种注入自身代理在类里Autowired或Resource注入UserService内部调用时用注入的实例。使用AopContext在配置里开启exposeProxytrue代码里用AopContext.currentProxy()拿到代理。XML场景对应aop:aspectj-autoproxy expose-proxytrue/。把内部调用的方法拆到另一个Bean里通过其他Bean的引用来调用这也是最符合Spring设计思路的做法。另一个边界是public方法限制。Spring AOP基于代理实现JDK动态代理本来就只能拦截接口里的方法而CGLIB虽然生成子类但Spring对非public方法的处理也很谨慎很多场景下private方法根本不会被拦截。结论很简单想让切面稳定命中目标方法就写成public。4.3 怎么确认当前Bean确实被代理了排查到某一步你可能已经怀疑这个Bean到底有没有被代理。怎么确认有几个土办法非常直观。第一种启动日志法。Spring启动时如果某个Bean被代理日志里会出现Bean xxx is a CGLIB proxy之类的提示不过不是所有日志级别都默认打印你可以临时把org.springframework.aop的日志级别调到DEBUG。第二种代码里检查类的结构。在目标类里临时注入一个自引用打印它的classAutowired private UserService userService; public void checkProxy() { System.out.println(userService.getClass()); System.out.println(userService instanceof UserService); }如果输出的是class com.sun.proxy.$Proxy123说明是JDK动态代理如果输出的是类似class com.example.service.impl.UserServiceImpl$$EnhancerBySpringCGLIB$$abcdef说明是CGLIB代理。如果输出就是class com.example.service.impl.UserServiceImpl本身那肯定没代理问题大概率是前面说的自动代理没开启或切面类没进容器。第三种用BeanFactory后置处理器探查。写一个BeanPostProcessor在postProcessAfterInitialization里把目标Bean的class打出来能看到完整代理链结构但这个方法侵入性强一般排查用第二种就够。5. 实测后的扩展玩法与性能注意事项5.1 自定义注解切面操作审计日志的标准姿势前面说的都是切所有Controller方法这种切法简单粗放但业务上常常只需要对个别特殊接口做审计。更精准的玩法是自定义一个注解谁标注了谁才被切。先定义一个注解Target(ElementType.METHOD) Retention(RetentionPolicy.RUNTIME) public interface OperLog { String module() default ; String action() default ; }切面里用annotation表达式匹配这个注解Aspect Component public class OperLogAspect { Pointcut(annotation(com.example.annotation.OperLog)) public void operLogPointcut() { } Around(operLogPointcut() annotation(operLog)) public Object recordOperLog(ProceedingJoinPoint joinPoint, OperLog operLog) throws Throwable { HttpServletRequest request ((ServletRequestAttributes) RequestContextHolder.getRequestAttributes()).getRequest(); String username getCurrentUsername(request); Object result; try { result joinPoint.proceed(); } catch (Exception e) { saveOperLog(username, operLog.module(), operLog.action(), 失败, e.getMessage()); throw e; } saveOperLog(username, operLog.module(), operLog.action(), 成功, null); return result; } }注意这里有一个小技巧annotation(operLog)把注解实例绑定到通知方法的参数上这样切面里才能拿到注解上写的module和action值实现同一个切面、根据标注产生不同的审计记录。Controller里的用法OperLog(module 订单模块, action 创建订单) PostMapping(/order/create) public Result createOrder(RequestBody OrderDTO dto) { // 业务逻辑 }这种方式的好处是审计规则完全由业务方决定不想审计的接口不加注解就行切面不需要维护一份方法清单。5.2 接口耗时统计与慢接口告警性能监控是AOP的另一个高频扩展。用Around把整个调用包起来记录开始时间和结束时间超过阈值就打点或发告警。Aspect Component public class PerformanceAspect { private static final Logger log LoggerFactory.getLogger(PerformanceAspect.class); Pointcut(execution(* com.example.service.impl.*.*(..))) public void servicePointcut() { } Around(servicePointcut()) public Object around(ProceedingJoinPoint joinPoint) throws Throwable { long start System.currentTimeMillis(); Object result; try { result joinPoint.proceed(); return result; } finally { long cost System.currentTimeMillis() - start; if (cost 1000) { log.warn(慢调用警告{} 耗时 {}ms, joinPoint.getSignature().toShortString(), cost); } } } }有些人会把耗时统计和请求日志写在同一个切面里省掉一个类的维护成本。我个人的建议是分开写两个切面各管各的一个挂了不影响另一个。多切面作用于同一个目标方法时执行顺序可以通过Order注解控制数字越小优先级越高这个顺序在切面之间有关联时非常关键比如权限校验必须优于日志记录。5.3 别把切面写成性能黑洞最后聊点实在的性能问题。AOP本身分派成本很低但很多人写着写着就在切面里干了重活把性能拖垮了还不自知。我的几条经验不要在切面里做同步数据库写入。比如上面的操作审计如果每来一个请求就同步插一条数据库记录在高并发下数据库压力会剧增。可靠的做法是把审计日志提交到线程池异步处理或者丢进消息队列。注意线程池的拒绝策略要有兜底别让日志把业务流量带崩。切点范围写窄写精确。前面说过execution(* com.example..*.*(..))这种全包匹配看起来省事但会让Spring为包下大量无关Bean也生成代理。代理本身有创建成本Bean数量多的时候启动时间和内存占用都会上升。能定位到哪一层就定位到哪一层。避免在切面里做远程调用。切面里调第三方接口一旦第三方超时所有被拦截方法的耗时都会被拖长而且排查问题时很难发现是切面造成的。如果真有这种需求一定要加超时控制、熔断和降级。多切面时注意顺序陷阱。举个例子如果同时存在事务切面和自定义性能统计切面性能统计的Around在最外层、事务的Around在内层你看到的耗时里就包含了事务提交的时长反过来就得考虑事务可能还没提交就已经打了统计日志。具体顺序要结合业务预期来定。我自己的另一个体会是AOP在Spring MVC项目里最划算的投入往往是先搭一个请求日志切面它几乎不涉及业务逻辑却能立刻让所有接口的调用情况变得可观测。等日志稳定了、没有误报了再往上面加权限、加审计、加性能监控每一步都在已有能力上叠加出错时也容易排查。很多人一上来就写一个巨大的多通知切面里面什么逻辑都有结果日志、权限、事务互相干扰反而把AOP的维护成本拉得比复制样板代码还高。这真不是夸张我在项目里见过太多类似的案例了。
