1. 项目概述：为什么我们需要深入理解Spring Boot AOP的代理机制？

如果你用过Spring Boot，那你肯定用过@Transactional、@Cacheable或者自定义的@Log注解。这些功能背后，几乎都离不开AOP（面向切面编程）的影子。但不知道你有没有遇到过这样的场景：一个加了@Transactional的方法，在同一个类内部调用另一个也加了@Transactional的方法时，事务竟然没生效？又或者，你写了一个接口，用Spring注入了一个实现类，但在某些情况下，这个实现类竟然不是你自己写的那个类，而是一个名字带$$EnhancerBySpringCGLIB$$的“奇怪”子类。这些“诡异”现象的背后，其实都指向了Spring AOP的核心实现机制——代理。

Spring AOP默认使用两种代理方式：JDK动态代理和CGLIB代理。这不仅仅是面试八股文里的一个知识点，更是直接影响你代码行为、性能表现乃至排查线上Bug效率的实战核心。很多人对它们的理解停留在“JDK代理基于接口，CGLIB基于类继承”的层面，但这远远不够。比如，为什么Spring Boot 2.x开始默认就用CGLIB了？CGLIB创建的代理对象，其内部方法调用顺序是怎样的？在什么情况下，即使你配置了CGLIB，Spring还是会“偷偷”给你用JDK代理？如果你对这些问题感到模糊，那么当遇到复杂的切面逻辑、循环依赖或者性能调优时，就很容易踩坑。

这篇指南的目的，就是带你穿透表面，从Spring容器的启动、Bean的创建过程开始，一步步拆解AOP代理的生成时机、底层原理、两种代理方式的详细差异，以及它们在实际开发中带来的那些“坑”和最佳实践。我会结合源码片段（用最易懂的方式解读）和大量实际测试案例，让你不仅知道“是什么”，更清楚“为什么”以及“怎么办”。无论你是想彻底搞懂Spring AOP的运行机制，还是正在被代理相关的Bug困扰，这篇文章都能给你提供清晰的路径和实用的解决方案。

2. AOP核心概念与代理模式快速回顾

在深入两种代理的细节之前，我们必须统一一下基础认知。AOP的目标是将横切关注点（如日志、事务、安全）从业务逻辑中分离出来。Spring AOP实现这一目标的主要手段，就是在运行时动态地创建一个代理对象，来包装你的目标对象（Target Object）。所有对目标对象的方法调用，都会先经过这个代理对象，代理对象则有机会在执行目标方法前后插入额外的逻辑（Advice）。

2.1 代理模式：静态与动态

这里主要涉及的是动态代理，它允许我们在运行时动态创建代理类，而不是在编译期。Spring AOP使用的两种技术，正是动态代理的两种主流实现。

• JDK动态代理：Java标准库自带的功能，位于java.lang.reflect.Proxy。它要求目标类至少实现一个接口。代理对象会实现这个接口，并将方法调用委托给一个InvocationHandler对象。
• CGLIB（Code Generation Library）代理：一个强大的第三方字节码生成库。它通过继承目标类来创建子类作为代理。因此，它不需要目标类实现接口。

2.2 Spring AOP中的关键角色

为了后续讨论更顺畅，我们先明确几个Spring AOP中的核心术语，它们直接关系到代理对象的生成和行为：

1. 目标对象 (Target)：你编写的、包含核心业务逻辑的原始Bean对象。
2. 切面 (Aspect)：封装横切关注点的模块，包含通知和切点。
3. 通知 (Advice)：切面中具体的动作，如@Before、@After、@Around等。
4. 切点 (Pointcut)：定义了通知应该应用到哪些连接点（方法）的表达式。
5. 连接点 (Join Point)：程序执行过程中可以插入切面的点，在Spring AOP中特指方法执行。
6. 代理对象 (Proxy)：Spring容器最终注入给其他Bean的、包裹了目标对象的对象。它融合了目标对象的行为和切面的逻辑。

理解了这些，我们就可以提出最核心的问题：Spring在什么时候、依据什么规则、如何选择使用JDK代理还是CGLIB代理来创建这个“代理对象”？

3. 代理的创建时机与决策逻辑

很多文章一上来就对比两种代理的区别，但忽略了Spring做出选择的关键上下文。这个选择并非在AOP配置时一锤定音，而是贯穿于Spring IoC容器创建Bean的复杂生命周期中。理解这个过程，是解决很多代理相关诡异问题的钥匙。

3.1 Bean的生命周期与代理插入点

Spring创建一个Bean的简化流程中，与AOP代理相关的关键步骤如下图所示（我们会在下文详细拆解）：

1. 实例化：调用构造函数创建原始对象（Target）。
2. 属性填充：进行依赖注入（@Autowired等）。
3. 初始化：执行@PostConstruct、InitializingBean接口等方法。
4. Bean后处理：这是代理创建的核心环节！在所有Bean初始化之后，Spring会遍历所有的BeanPostProcessor。其中有一个至关重要的处理器——AnnotationAwareAspectJAutoProxyCreator（或其父类AbstractAutoProxyCreator）。

这个AbstractAutoProxyCreator是一个BeanPostProcessor，它会在每个Bean初始化完成后，检查这个Bean是否需要被代理。如果需要，它就会拦截这个Bean，并返回一个代理对象来代替原始Bean，后续容器中存储和注入的都是这个代理对象。

3.2 决策逻辑：Spring如何选择JDK还是CGLIB？

AbstractAutoProxyCreator的createProxy方法是决策的核心。其逻辑可以概括为以下流程图，它清晰地展示了Spring Boot不同版本下默认行为的变化以及最终的决策路径：

flowchart TD A[开始: 为目标Bean创建代理] --> B{目标Bean是否有实现接口?} B -- 是 --> C[Spring Boot < 2.0 或<br>spring.aop.proxy-target-class=false] B -- 否 --> D[强制使用CGLIB代理] C -- 是 --> E[使用JDK动态代理] C -- 否 --> F[使用CGLIB代理] D --> G[代理创建完成] E --> G F --> G

上图揭示了几个关键点：

1. 首要条件（接口）：如果目标Bean没有实现任何接口，Spring别无选择，只能使用CGLIB（因为JDK动态代理要求必须有接口）。这是上图中右侧的强制路径。
2. 配置优先：如果目标Bean实现了接口，Spring会首先检查配置。在Spring Boot 2.0之前，默认proxy-target-class是false，即优先使用JDK动态代理。而在Spring Boot 2.0及以后，为了支持更多特性（如@Cacheable在非接口方法上的代理），默认值改为了true，即优先使用CGLIB代理。你可以通过spring.aop.proxy-target-class来显式覆盖这个默认行为。
3. 强制CGLIB的场景：除了配置，还有一些情况会强制使用CGLIB：
   • 切面配置了proxy-target-class="true"。
   • 使用了基于Schema的AOP配置并设置了proxy-target-class="true"。
   • 目标对象本身已经是另一个CGLIB代理（为了避免代理链混乱）。

重要提示：这个决策过程发生在每个Bean创建时。这意味着，同一个应用里，不同的Bean完全可能采用不同的代理方式，取决于它们自身的结构和全局配置。

3.3 如何直观判断当前Bean使用了哪种代理？

在调试或日志中，你可以快速判断：

• JDK动态代理：代理对象的类名通常类似$Proxy123，它是java.lang.reflect.Proxy的子类，同时实现了你的业务接口。使用proxy.getClass().getInterfaces()可以看到它实现的接口。
• CGLIB代理：代理对象的类名通常类似YourServiceImpl$$EnhancerBySpringCGLIB$$12345678，它是你目标类的子类。使用proxy.getClass().getSuperclass()可以看到它的父类是你的原始业务类。

4. JDK动态代理深度解析

4.1 工作原理与源码窥探

JDK动态代理的核心是java.lang.reflect.Proxy.newProxyInstance方法。我们来看一下Spring中与之相关的简化逻辑：

// Spring的 JdkDynamicAopProxy 类核心方法 public Object getProxy(@Nullable ClassLoader classLoader) { // 获取目标对象实现的所有接口 Class<?>[] proxiedInterfaces = AopProxyUtils.completeProxiedInterfaces(this.advised); // 调用JDK原生API创建代理实例 return Proxy.newProxyInstance(classLoader, proxiedInterfaces, this); }

这里的this（即JdkDynamicAopProxy实例）本身就实现了InvocationHandler接口。当代理对象上的方法被调用时，会触发其invoke方法：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { MethodInvocation invocation; // 1. 获取目标对象（原始Bean） Object target = getTarget(); // 2. 获取该方法对应的拦截器链（由切面通知构成） List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, target.getClass()); // 3. 如果没有拦截器，则直接反射调用目标方法 if (chain.isEmpty()) { return method.invoke(target, args); } // 4. 如果有拦截器，则创建一个方法调用链，并依次执行通知逻辑和目标方法 invocation = new ReflectiveMethodInvocation(proxy, target, method, args, target.getClass(), chain); return invocation.proceed(); }

关键点：

• 代理对象与目标对象分离：代理对象（$Proxy123）和目标对象（你的原始Bean）是两个不同的对象实例。代理对象持有目标对象的引用。
• 基于接口：所有方法调用都通过接口进行路由。这意味着，如果你将代理对象强制转换为目标类的具体类型（而不是接口），将会抛出ClassCastException。
• 性能：由于使用Java反射调用目标方法，在大量调用时会有一定的性能开销，但现代JVM对反射进行了大量优化，这个开销在大多数场景下可以接受。

4.2 JDK动态代理的典型“坑”与应对

1. “自我调用”导致切面失效这是最经典的坑。看下面代码：

   @Service public class UserServiceImpl implements UserService { @Override @Transactional public void createUser(User user) { // 一些操作... this.updateUserStatus(user.getId(), "ACTIVE"); // 注意这里的 this } @Override @Transactional(propagation = Propagation.REQUIRES_NEW) public void updateUserStatus(Long userId, String status) { // 更新状态... } }

   你期望updateUserStatus会以新事务运行，但实际上它根本不会生效。因为createUser方法中的this指的是目标对象本身，而不是它的代理对象。调用this.updateUserStatus()完全绕过了代理，直接进入了目标对象的方法，事务切面自然没有机会介入。

   解决方案：

   • 最佳实践：避免在同一个Bean内部进行带有切面的方法调用。将updateUserStatus方法抽取到另一个Service中。
   • 变通方法：从ApplicationContext中获取当前Bean的代理对象再进行调用（不推荐，耦合度高）。
   • 使用AspectJ：切换为AspectJ的编译时或加载时织入（LTW），可以解决此问题，但会增加复杂性。

2. 只能代理接口方法如果你的Service类有一个public方法没有在接口中声明，那么即使这个方法匹配切点，JDK动态代理也无法为它创建代理。调用该方法时，切面逻辑不会执行。

5. CGLIB代理深度解析

5.1 工作原理：字节码生成与子类化

CGLIB通过操作字节码（ASM库）在运行时动态生成目标类的一个子类。这个子类重写了父类（即目标类）中所有非final的方法。我们看看Spring中CglibAopProxy的关键逻辑：

// 简化版的CGLIB代理创建过程 public Object getProxy(@Nullable ClassLoader classLoader) { // 创建Enhancer（CGLIB的核心类） Enhancer enhancer = new Enhancer(); // 设置父类（即我们的目标类） enhancer.setSuperclass(this.advised.getTargetClass()); // 设置回调，即方法拦截器 enhancer.setCallback(this); // this 是 DynamicAdvisedInterceptor // 创建代理子类实例 return enhancer.create(); }

当代理子类的方法被调用时，会进入回调拦截器（DynamicAdvisedInterceptor.intercept）：

public Object intercept(Object proxy, Method method, Object[] args, MethodProxy methodProxy) throws Throwable { // 1. 获取目标对象（注意：这里的目标对象是原始对象，但方法调用方式不同） Object target = getTarget(); // 2. 获取拦截器链 List<Object> chain = this.advised.getInterceptorsAndDynamicInterceptionAdvice(method, target.getClass()); // 3. 如果没有拦截器，则通过CGLIB的FastClass机制直接调用父类（目标）方法 if (chain.isEmpty()) { return methodProxy.invokeSuper(proxy, args); // 注意这里是 invokeSuper } // 4. 有拦截器，则构建调用链 CglibMethodInvocation invocation = new CglibMethodInvocation(proxy, target, method, args, target.getClass(), chain, methodProxy); return invocation.proceed(); }

关键点：

• 继承关系：代理对象是目标对象的子类实例。这意味着proxy instanceof YourServiceImpl会返回true。
• 方法调用机制：CGLIB通常使用MethodProxy.invokeSuper来调用父类（即目标对象）的原始方法。这种方式比JDK的反射调用更快，因为它为每个方法建立了索引，避免了反射查找。
• 限制：由于是继承，所以无法代理final方法（不能被重写）、private方法（子类不可见）以及static方法。

5.2 CGLIB代理的典型“坑”与应对

1. 默认构造函数与Bean初始化CGLIB通过继承来创建代理，因此它必须能够调用到目标类的默认（无参）构造函数。如果你的目标类只有带参数的构造函数，那么CGLIB将无法实例化代理子类，会抛出异常。

   注意：这个限制在Spring中通常不是问题，因为Spring实例化原始Bean时已经通过构造函数完成了，CGLIB创建的是子类，它调用父类构造器时使用的是super()，所以目标类必须有一个可访问的无参构造器（可以是默认的）。

2. “自我调用”问题依然存在是的，CGLIB同样无法解决同一个Bean内部方法调用导致的切面失效问题。原理和JDK代理类似：内部调用时的this仍然是目标对象本身，而不是代理对象。

3. Final方法的陷阱如果你有一个public final方法，并且为它配置了切面（例如@Transactional），CGLIB无法代理这个方法。调用这个方法时，切面逻辑不会执行，而且不会有任何错误或警告！这是一个静默的失败，非常危险。排查建议：在编写Service类时，尽量避免使用final修饰符，除非你有非常明确的理由。

4. 性能与创建开销CGLIB在创建代理对象时比JDK动态代理慢，因为它需要生成和加载新的字节码。但是，在方法调用时，由于其FastClass机制，通常比JDK动态代理的反射调用要快。对于Singleton作用域的Bean（Spring默认），创建开销只有一次，所以运行时性能优势更值得关注。但对于Prototype作用域的Bean，频繁创建可能会带来一些开销。

6. 两种代理方式的对比与选型指南

现在，我们可以从多个维度系统性地对比两者，并给出选型建议。

选型建议与最佳实践：

1. 跟随Spring Boot默认：对于大多数Spring Boot 2.x+项目，直接使用默认的CGLIB是省心且稳妥的选择。它避免了“类未实现接口导致无法代理”的尴尬，对@Cacheable、@Async等注解的支持也更一致。
2. 明确使用JDK动态代理的场景：
   • 你希望强制遵循“面向接口编程”，并且所有被代理的Bean都严格实现了接口。
   • 目标类已经是其他类的子类（Java单继承限制），无法再被CGLIB继承。
   • 在一些极其注重代理对象创建速度，且Bean生命周期短（如Prototype）的特殊场景下。
3. 强制使用CGLIB的场景：
   • 目标类没有实现任何接口（这是强制性的）。
   • 你需要代理一个没有在接口中定义的方法。
   • 你使用了@Configuration注解的配置类，其内部@Bean方法之间的调用也需要被代理（Spring配置类特殊处理，通常使用CGLIB）。
4. 通用注意事项：
   • 永远不要依赖内部方法调用：无论使用哪种代理，都要避免在同一个Bean内部调用另一个具有切面逻辑的方法。这是AOP设计上的一个局限，通过代码结构设计来规避。
   • 谨慎使用final：在可能被AOP代理的类上，避免使用final修饰符。
   • 理解代理对象的真实类型：在调试、日志或需要获取Bean类型时，心里要清楚你拿到的是代理对象，不是原始对象。

7. 高级话题与疑难排查

7.1 配置类（@Configuration）的特殊代理

用@Configuration标注的类是一个特例。Spring会使用CGLIB对其进行增强，目的是拦截其中@Bean方法之间的调用，确保返回的是同一个单例Bean。如果你在配置类内部直接调用另一个@Bean方法，Spring会通过代理确保你得到的是容器中已存在的Bean，而不是每次调用都创建一个新实例。这是Spring保证@Bean方法单例行为的关键机制。

7.2 多种AOP并存时的代理顺序

一个Bean可能被多个切面匹配（比如既有事务管理@Transactional，又有自定义日志@Log）。Spring会将这些通知（Advice）组织成一个拦截器链（Interceptor Chain）。这个链的顺序由@Order注解或实现Ordered接口来决定，数字越小，优先级越高，越在外层。

对于@Around通知，你可以想象成一个洋葱。优先级最高的通知在最外层，它先执行proceed()前的代码，然后将调用传递给链中的下一个通知，最终到达目标方法，然后再以相反的顺序返回。

7.3 常见问题排查清单

当你发现AOP不生效时，可以按照以下清单进行排查：

1. Bean是否被Spring管理？检查类是否有@Component、@Service等注解，是否在组件扫描路径内。
2. 方法是否是public的？Spring AOP默认只代理public方法。protected、private方法上的切面注解无效。
3. 调用方式是否正确？是否是“自我调用”？从其他Bean调用是否正常？
4. 切点表达式是否正确？确认你的@Pointcut或注解确实匹配到了目标方法。可以在切面类里加日志或断点调试。
5. 使用了哪种代理？通过bean.getClass().getName()打印类名，判断是JDK代理还是CGLIB代理。如果是CGLIB，检查目标方法是否是final的。
6. 多个切面的顺序问题？检查是否有切面通过@Order设置了顺序，导致某个切面的逻辑被意外覆盖或跳过。
7. 异常被“吞”掉了？在@Around通知中，如果捕获了异常但没有重新抛出，会导致调用方感知不到异常，比如事务回滚失效。

7.4 性能调优考量

• 代理创建开销：对于Singleton Bean，代理只创建一次，开销可忽略。对于Prototype或每次请求都新建的Bean，如果数量巨大，CGLIB的字节码生成开销可能成为瓶颈，此时可考虑JDK代理或调整作用域。
• 切点表达式优化：过于宽泛或复杂的切点表达式（如execution(* com.xxx..*.*(..))）会在每次方法调用时都进行匹配计算，影响性能。尽量使用更精确的切点，或考虑使用@annotation等开销较小的指示器。
• 通知类型选择：@Around是最强大的，但也是开销最大的。如果@Before、@AfterReturning、@AfterThrowing能满足需求，优先使用它们。

理解Spring Boot AOP中CGLIB与JDK动态代理的差异，绝非仅仅为了应付面试。它直接关系到你能否写出行为符合预期的代码，能否高效地排查那些因代理机制引发的隐蔽Bug。从Spring容器的Bean生命周期出发，看清代理对象被创建和注入的时机；从两种代理的底层原理出发，理解它们各自的能力边界和陷阱。当你再遇到事务不生效、缓存不起作用、日志打不出来这些问题时，你的排查思路会清晰得多——先看代理类型，再查调用链路，最后验证切面逻辑。记住，在Spring的世界里，你写的Bean和你实际用到的Bean，中间可能隔着一个“代理”，而这个代理的“性格”（是JDK还是CGLIB），则由配置、类结构和Spring的版本共同决定。掌握它，你就掌握了Spring AOP最核心的一把钥匙。