SpringAOP 这个东西很多人用了好几年配置几个注解就能拦方法、记日志、做权限看起来挺神奇。但如果只停在“会用”这个层面遇到事务不生效、切面被跳过、代理对象没生成这类问题基本就只能靠猜。我自己的体会是搞懂 SpringAOP 原理收益最大的不是面试而是排查问题的时候思路会完全不一样。这篇就把 SpringAOP 从概念到执行链路再到事务和 AOP 的关系从头到尾拆开讲一遍内容偏实战也会把底层细节说透适合已经从“会用注解”进阶到“想看明白为什么”的 Java 开发。1. SpringAOP本质到底是什么一次Bean初始化就够了吗1.1 代理模式是AOP的骨架AOP 想做的一件事本质上是“在不修改业务类源码的情况下往方法调用前后插入逻辑”。要实现这件事绕不开的就是代理模式。代理模式的核心思路很简单客户端不直接调用目标对象的方法而是调用一个代理对象的方法代理对象在调用前后做点额外的事情再把调用转发给目标对象。SpringAOP 在运行期做的事情可以概括为两句话一是所有符合切点表达式的 Bean 都会被换成一个代理对象二是这个代理对象在内部维护了一个“拦截器链”方法入口走到代理时就按顺序执行拦截器链最后才真正调用目标方法。这里必须强调一个容易混淆的点SpringAOP 不是像 AspectJ 那样在编译期或者类加载期修改字节码生成切面逻辑而是在运行期“动态生成代理类”。也就是说你的业务类字节码没变变成的是 Spring 容器里那个 Bean 的引用。你在代码里注入的、拿到的那个对象从头到尾都不是你写的那个 class 的实例而是一个代理实例。理解这点是理解后面所有问题的起点。1.2 JDK动态代理与CGLIB为什么Spring Boot 2.x开始默认CGLIB动态代理有两种实现路线JDK 动态代理和 CGLIB。JDK 动态代理要求目标类必须实现至少一个接口代理类和目标类实现同一接口通过 InvocationHandler 把方法调用转发出去。它的好处是不依赖第三方库JDK 自带的但局限也很明显目标类没有接口就完全无能为力。CGLIB 走的是继承路线它为目标类生成一个子类在子类里重写父类方法通过 MethodInterceptor 拦截方法调用。因为是基于继承所以目标类如果是 final 的方法如果是 final 或 private 的都没法被代理。CGLIB 在生成子类时会修改方法字节码性能开销和类加载成本都比 JDK 代理要高一点但胜在“不需要接口”这个能力。Spring Boot 2.x 之后spring.aop.proxy-target-class 的默认值从 false 改成了 true也就是说默认走 CGLIB。社区对这个改动的讨论非常多支持者认为大部分业务类根本没有设计接口强制接口反而增加无意义的代码反对者担心 CGLIB 的额外开销和 final 方法限制。我在实际项目里的感受是Spring Boot 默认 CGLIB 后日常使用中几乎没有感知到性能差异反而是以前 JDK 代理“目标类必须实现接口”这个限制让很多老代码只能为了代理而硬拆接口特别烦人。所以这个默认值改动我双手赞成。1.3 对象是在哪里被换包成代理的接着回答标题里的这个“够了吗”的问题一次 Bean 初始化肯定是“不够的”因为代理对象的生成并不是类加载时发生的而是 Spring 容器在管理 Bean 生命周期时“篡改”了最终结果。Spring 容器创建 Bean 的流程大致是这样实例化 - 属性填充 - 初始化。在初始化阶段Spring 会执行一系列 BeanPostProcessor其中有一个叫做 AnnotationAwareAspectJAutoCreator 的特殊后置处理器。这个名字有点长但它的作用非常核心在 Bean 初始化完成后判断这个 Bean 是否匹配任意切面Aspect如果匹配就调用 AOP 基础设施生成代理对象并把代理对象返回给容器。容器拿到这个代理对象后会把它注册进单例池后续所有依赖注入和 getBean 拿到的都是这个代理对象而不是原始 Bean。所以你在一个 Service 里注入另一个 Service 时拿到的引用就已经是代理了只是你自己感知不到。这里有个典型的直觉陷阱你会觉得代理是注解帮我们加的但 SpringAOP 生效的底层完全依赖 BeanPostProcessor 这个机制。如果你哪天把 EnableAspectJAutoProxy 去掉或者扫描路径没覆盖到切面类那些注解、切点表达式全都不会生效而且不会有任何编译期报错只有在运行时观察行为才能发现。这点必须时刻记在心里。2. 切点、通知与AdvisorAOP规则的注册与匹配逻辑2.1 通知模型与切点表达式SpringAOP 里有几个常见概念切点Pointcut表示“哪些方法要被拦截”通知Advice表示“拦截后做什么逻辑”切面Aspect就是切点加通知的组合。通知又有五种类型前置通知、后置通知、返回通知、异常通知、环绕通知。从使用频率来说环绕通知独占鳌头因为它的形态最灵活。环绕通知的参数是 ProceedingJoinPoint你可以决定是否继续执行目标方法、也可以修改返回值、可以捕获异常后做补偿。其实从实现细节看Spring 内部会把其他几种通知都转换成一种统一的拦截器模型在合适的位置回调对应的方法。切点表达式是另一大块。最常见的写法是 execution(public * com.example.service..*Service.*(..))它的语义是“匹配 com.example.service 包及其子包下所有以 Service 结尾的类的所有 public 方法”。表达式还有 within、this、target、args、annotation 等写法分别从类类型、代理对象类型、目标对象类型、参数类型、注解标记等维度做匹配。我建议在项目里切点表达式写得太宽容易误伤写得太窄又容易漏。比如直接写 execution(* *..*(..))等于拦截所有方法这个除了做性能监控几乎没有场景需要。更合理的做法是把切点定义成独立方法加上 Pointcut 注解多个通知可以复用同一个表达式后期维护时只改一处。这个习惯能帮你省下大量排查“为什么这里也会被拦截”的时间。2.2 Advisor链与多切面的执行顺序一个方法可能同时匹配多个切面那就涉及顺序问题。SpringAOP 内部把每一个“切点通知”的组合封装成一个 Advisor一个目标方法上的所有 Advisor 会被组合成一个拦截器链按照排好的顺序逐个执行。顺序的规则是这样的Order 注解的值越小越先执行。如果是实现了 Ordered 接口的方式也同理。没有显式指定顺序的时候Spring 会按切面类的名称和注册顺序等规则默认排序但这是“不确定”的一旦系统里有多个切面又对顺序敏感必须显式指定。这里有一个非常经典的顺序误区很多人以为前置通知和后置通知的顺序是“按 Order 从前到后”实际上环绕逻辑是这样的——假设有两个切面 A 和 BA 的 order 值更小那么 A 先执行但它的 finally 部分后置逻辑是最后执行的。整体效果是一个嵌套结构A的前置 - B的前置 - 目标方法 - B的后置 - A的后置。我在多团队协作的项目里就见过一个案例一个切面做性能埋点另一个切面做权限校验因为没指定顺序日志里权限校验的时间戳经常把埋点时间全部包进去数据整体偏移查半天才发现是顺序问题。2.3 AspectJ注解解析背后的排序实现Spring 解析 Aspect 注解标注的类时会调用 AspectJ 的工具类比如 ReflectiveAspectJAdvisorFactory来解析。扫描所有切面 Bean 后把每个带通知注解的方法解析成 Advisor。这一步不仅解析方法名、参数、注解类型还会解析切点表达式构建切点匹配器。这个解析过程从代码层面看核心是一个 Advisors 的列表。Spring 会调用 advisor 排序方法规则牵扯到多个维度如果实现了 Ordered 接口按 getOrder 比较如果是同一个切面类内定义的多个通知则按通知类型的“优先级顺序”排——具体来说 Spring 对 Before、AfterReturning、AfterThrowing、After、Around 有一套内部排序逻辑以确保语义正确。实际项目里如果你发现一个切面里的前置通知和环绕通知执行的先后和预期不一致大概率是没有在这个切面内部理清通知类型的排序规则。最稳妥的方案是同一个切面里所有需要强顺序的拦截逻辑合并到一个环绕通知里用代码控制顺序而不是依赖框架的隐式排序。我这几年一直是这么做的省了很多莫名奇妙的麻烦。3. 代理对象执行链路详解方法与异常的真实流转3.1 方法执行时代理对象到底做了什么下面我把一次完整的方法调用链路走一遍。假设 Controller 调用了 Service 的 query 方法而这个 Service 被 AOP 代理了。实际调用流程如下第一步Controller 持有的引用是代理对象所以 query 方法的调用会先进到代理的逻辑。 第二步代理对象会拿到目标方法对应的 Method 对象以及一个拦截器链Advisor 链。 第三步代理会执行一个递归调用链核心是 ReflectiveMethodInvocation。这个类的 proceed() 方法会逐个执行拦截器执行到最后一个拦截器时再通过反射调用真正目标对象的方法。JDK 动态代理的实现里这个调用会进入 InvocationHandler 的 invoke 方法由 JdkDynamicAopProxy 统一接管再创建 ReflectiveMethodInvocation 并执行。CGLIB 的实现则略有不同代理对象内部是一个 MethodInterceptor 回调最终也会落到 ReflectiveMethodInvocation 上做统一处理。所以无论哪种代理方式执行链的模型是共享的。这里我想强调一个细节代理对象从拿到方法到执行拦截会有一次“方法匹配”的过程。也就是说即使某个 Bean 生成了代理对象当它调用一个不符合切点的方法时代理内部会直接选择“本方法不拦截”快速跳到目标方法开销很小。但如果方法匹配上了后续每调用一次都会按拦截器链走一遍。所以切点表达式里写“匹配哪些包、哪些注解”不只是表达意图还直接影响每次方法调用的执行路径开销。3.2 异常处理语义异常在代理链路中的流转也很关键。环绕通知里如果你用 try-catch 把 ProceedingJoinPoint.proceed() 包住了并且捕获后没抛出去那么目标方法抛出的异常就被吞掉了后续的异常通知也不会执行。这是一个常见的设计决策点到底应不应该吞异常。再往细里看异常通知和返回通知的触发条件有细微差别。返回通知AfterReturning是“正常返回后”才触发如果方法抛了异常它不会执行。异常通知AfterThrowing则是“方法抛出异常”后触发。后置通知After无论是否抛异常都会执行类似 finally。这个语义如果不清楚很容易把“无论如何都要做的清理逻辑”错放在 AfterReturning 里导致异常场景下清理逻辑不执行资源泄漏。我在项目里遇到过一种很隐蔽的线上问题某个方法通过环绕通知做了主从数据源切换但异常发生时环绕通知没有在 finally 里恢复数据源上下文导致后续请求全部路由到了从库。这个问题没有报错只有慢查询告警才能观测到。最终修复就是在环绕通知里把数据源上下文的清理放到 finally 中。这类问题不是 SpringAOP 的 bug而是对执行语义理解不完整导致的。3.3 环绕通知是所有组合通知的底层实现从内部实现看SpringAOP 的拦截器链并不区分你写的到底是前置通知还是后置通知它会把所有通知统一包装成一个个 AdvisorAdapter 对应的拦截器。前置通知会被包装成 MethodBeforeAdviceInterceptor后置通知会被包装成 AfterReturningAdviceInterceptor异常通知则是 ThrowsAdviceInterceptor。这些拦截器统一实现 MethodInterceptor 接口放进拦截器链一起执行。由于所有通知最终都被转换成了环绕通知形态的拦截器所以从“精简理解”的角度你可以把 SpringAOP 的整套执行链路简化成“一条环绕通知链”。虽然没有直接写一个大的环绕通知但最终执行效果差不多。这也是我为什么一直建议项目里写切面逻辑时优先用环绕通知而不是分散地写多个不同通知类型。代码集中、可读性好、异常控制明确排查问题的成本会低很多。不过要提醒一点环绕通知里如果没有调用 proceed()目标方法就不会执行。这个“能力”有时候是精心设计的比如你想做一个基于 blacklist 的熔断拦截掉某方法不执行直接返回兜底结果。但有时候这是 bug比如条件判断写反了把不该跳过的逻辑跳过了。排查这类问题时优先检查环绕通知的 proceed() 调用位置是最快的路径。4. Spring事务与AOP的化学关系4.1 声明式事务本质是AOP环绕通知Spring 的声明式事务之所以能用 Transactional 一个注解搞定本质上就是因为它基于 AOP。Spring 内部有一个 TransactionInterceptor它实现了 MethodInterceptor 接口核心逻辑是这样的在方法执行前根据事务属性开启事务然后调用 proceed() 执行业务方法如果业务方法正常返回就提交事务如果抛出异常就回滚事务并重新抛出异常。这就解释了为什么事务功能和 AOP 功能天然共享同一套基础设施。你甚至可以这么理解Transactional 就是一个“半成品”的环绕通知只不过它的拦截逻辑是固定的事务开启、提交、回滚而不是你自定义的日志、权限逻辑。这个理解能帮你快速判断一类问题——事务是否生效首先取决于方法是否经过代理对象。我见过太多人把事务失效归因于“驱动不对”“数据库不支持事务”但真实情况往往是方法根本没有被 AOP 管理到。比如你在同一个类里写了一个方法调用另一个带 Transactional 的方法这种自调用不会经过代理事务绝不会生效。这个在前面的第 1.3 节已经埋过伏笔只有通过容器注入的代理引用调用方法才会被拦截this 调用不会。4.2 5个典型的事务失效场景我整理了几个实际项目中最高频的事务失效场景每一个几乎都踩过建议收藏备用。场景一同类自调用。同一个 Service 里的方法 A 调用方法 B而 B 上有 Transactional。这种情况下调用的是 this 的方法根本不走代理事务完全被绕过。场景二方法不是 public。Spring 事务默认只对 public 方法生效。如果 Transactional 标注在 private 方法上虽然编译不报错但事务不会开启。CGLIB 代理下private 方法根本没法被子类重写覆盖就无法进行事务拦截。场景三异常被吞掉。业务代码里用 try-catch 把异常捕获住了没有抛出去事务拦截器看到的是“方法正常返回”自然就提交了不会回滚。这个是最隐蔽的一个坑。场景四抛出的是 checked exception。Spring 事务默认只对 RuntimeException 和 Error 回滚。如果你抛出一个自定义的 checked exception事务同样不会回滚。除非在 Transactional 注解里显式指定 rollbackFor Exception.class。场景五数据库表引擎不支持事务。比如 MySQL 的 MyISAM 引擎DDL 都能正常执行但事务压根没被支持。这种情况从代码层面看不出任何问题只能靠检查建表语句修复。平时排查事务失效问题时我会按这个顺序逐条核对先确认方法是否通过代理调用再确认修饰符是不是 public接着查异常有没有被吞、类型对不对最后才怀疑数据库层配置。按这个思路走95% 的问题都能快速定位。4.3 事务传播行为与回滚规则的联动除了失效问题事务的另一大难点是传播行为。Spring 默认的传播行为是 REQUIRED如果当前已经存在事务就加入不存在就新建。这个默认值在绝大多数单体请求里是合理的因为一个请求链路里多个 Service 方法往往应该共享同一个事务。但传播行为一旦和 AOP 代理叠加就会出现一些反直觉的行为。比如 PROPAGATION_REQUIRES_NEW它表示不管当前有没有事务都挂起当前事务、新建一个新事务。这个新事务的开启和提交、回滚都只限定在被拦截的这个方法内部。如果你在这个方法里 try-catch 了异常外层事务可能感知不到内层的事务已经回滚了导致外层继续提交产生“部分成功”的不一致状态。另一个容易踩的是 PROPAGATION_NESTED。它和 REQUIRES_NEW 的区别在于嵌套事务是外层事务的一部分通过 savepoint 实现内层回滚后外层可以继续走到提交分支。这个特性很实用但要注意它对数据库和连接池有一定要求不是所有环境都能表现稳定。我在实际项目中建议除非特定场景必须用 REQUIRES_NEW 或 NESTED否则尽量保持默认的 REQUIRED。传播行为越多事务边界越复杂线上排查越痛苦。4.4 事务与AOP使用的性能考量AOP 本身有一层间接调用事务拦截器又裹了一层所以“代理方法调用”相比“直接方法调用”会有额外的栈帧开销和反射调用开销。在现代 JVM 上这部分开销微乎其微绝大多数业务系统完全不用关心。但如果你的系统里有一个高频调用方法例如每秒执行上万次且每次都要走 AOP 拦截链那确实有必要在意。优化思路有几类一是精细化切点让高频方法不在匹配范围内二是减少拦截器链的长度多个切面能合并的尽量合并三是如果把代理类的调用改为直接调用非代理 Bean但这样会失去 AOP 能力属于极端优化方式不建议轻易做。我碰到过一个极端案例一个网关项目对每个请求都做了权限校验切面、限流切面、审计切面三个切面套在一起某个核心接口 QPS 一上来CPU 飙到接近满载。后来我们发现某个切面里做了大量反射获取注解的操作且每调用一次都会重复解析。修复方式是一级缓存缓冲注解元数据最终 CPU 占用直接降了 30%。这其实是反射与 AOP 叠加后放大的问题不是代理本身多么昂贵。5. 定位与排查SpringAOP问题的实战技巧5.1 先看Bean是否是代理对象排查任何 AOP 相关问题第一步永远是确认“你拿到的到底是不是代理对象”。最简单的方法是在方法内部打印对象的 ClassSpring 代理对象通常带有 class 关键字比如 com.sun.proxy.$Proxy 开头的说明是 JDK 动态代理如果看到 com.example.service.Service$$EnhancerBySpringCGLIB$$xxx说明是 CGLIB 代理。也可以通过 AopContext.currentProxy() 或者手动注入 BeanFactory 后判断。还有一种更直接的调试技巧在注解拦截器不生效时你可以在启动时加代理信息日志。Spring 提供了 BeanFactory 的 isAopUtils 工具类AopUtils.isAopProxy(bean) 返回 true 就说明当前 Bean 是代理。用这种方式在代码里主动断言能在问题刚发生时就暴露出来省去绕弯子排查的时间。5.2 切点没生效的排查顺序切点没生效是我的读者群和项目群里最常被问的问题没有之一。我总结了一套排查顺序跟着走基本能找到根因第一步确认切面类是否被 Spring 扫描到。Spring 中切面类本身要注册成 Bean如果 Aspect 类上缺少 Component或者扫描路径没覆盖到切面类压根就不存在。第二步确认是否开启了 AOP 支持。Spring Boot 项目一般自动开启但还是要注意如果你用纯 Spring 项目手动配置必须加上 EnableAspectJAutoProxy 或者在 XML 里配置 aop:aspectj-autoproxy/ 。第三步确认切点表达式的匹配范围。把 execution 表达式的包路径、方法修饰符、返回值类型一个个核对尤其注意包名拼写错误和通配符使用问题。很多“切面没生效”其实是切点匹配了“完全不同的包路径”而已。第四步确认方法是否被绕过代理。这个靠第 5.1 节的方式判断代理是否存在。如果 Bean 不是代理后面所有分析都没有意义。按这个顺序排查完仍然没找到那就需要在切面通知方法里打日志确认通知方法本身有没有被调用。如果通知方法被调了但“看起来没效果”那就是通知内部逻辑或方法返回值处理的问题了。5.3 开启AOP调试日志Spring 的 AOP 是支持日志输出的尤其在 DEBUG 级别下会打印非常详细的代理创建和匹配信息。配置方式很简单把 org.springframework.aop 的日志级别调到 DEBUG就能看到这类输出Creating implicit filter for ...、Using ... as advisor 等。日志里的关键信息包括某个 Bean 被判断为可以代理、生成了哪种代理对象、哪些 Advisor 会被应用、某个方法是否匹配切点。这些信息比盲目打断点高效得多尤其在多切面场景下它能直接告诉你整个拦截器链的组装结果。我在定位一次“某个类频繁被 foreach 循环代理”的问题时就是靠 DEBUG 日志快速确认了是某个外部依赖包里的类也被纳入了切点范围导致这个类实例化的每个对象都在疯狂创建代理。调整切点表达式后问题立刻消失。这种场景如果没有日志得靠 IDE 一个类一个类地找效率完全不一样。写在最后的经验回头看我接触 SpringAOP 这几年最大的体会是它的核心矛盾永远在代理与目标对象之间。不管你是理解事务失效还是排查切面被跳过只要抓住“Bean 到底是不是代理、方法调用到底走没走代理”这个主线任何疑难杂症都能找到方向。另一个让我反复受益的习惯是遇到复杂 AOP 问题时先去查日志而不是直接断点调试日志给出的上下文和决策过程往往更直观。如果你刚开始学 SpringAOP 原理不用急着把实现源码背下来先把动态代理、拦截器链、事务拦截器这三件事连成一条线再遇到问题时回头验证。这套知识体系会让你在真实项目中少踩一半的坑。