1. 为什么 Spring 的 Bean 会“变脸”一次依赖注入引发的思考先从一个很常见的现象说起。我早期做项目的时候特别爱在 Service 层加日志切面统计每个方法的耗时。当时写完一个Aspect信心满满地启动项目打开控制台一看——日志一条都没打印。排查了一上午最后发现原因特别无语那个 Service 类的方法被自己同类内部的另一个方法调用了压根没走代理。这个经历其实引出了 Spring 容器里最容易被忽略的一件事你从容器里拿到的 Bean很多时候根本不是你自己写的那个类的实例而是它的“替身”。这个替身能识别你的方法调用然后偷偷穿插一些额外逻辑再回头执行你原来的方法——这就是 AOP面向切面编程能生效的根基。而这个“替身”的生成方式在 Java 世界里主要就两条技术路线JDK 动态代理和 CGLIB。很多初学者会把这两者当成面试题背一背“JDK 代理基于接口CGLIB 基于继承Spring Boot 2.x 之后默认 CGLIB”好像会背就完事了。但我在实际项目里踩过不少坑之后发现这两者的差异远不只是“接口 vs 继承”这么简单。它们各自的底层原理、性能特征、适用边界甚至在不同 JDK 版本下的表现都深刻影响着你在 Spring 里怎么设计类、怎么切面、怎么排查问题。这篇内容我不打算泛泛而谈概念而是把我实际使用过程中的理解、验证过程、踩坑记录都摊开来讲尽量让你看完之后既能应付面试也能真正在项目里用对。2. JDK 动态代理只认接口的“谈判专家”2.1 一段能跑的最小示例先来一个最简单、能立刻运行的 JDK 动态代理示例。假设我们有一个接口和一个实现类public interface OrderService { void createOrder(String orderNo); } public class OrderServiceImpl implements OrderService { Override public void createOrder(String orderNo) { System.out.println(创建订单 orderNo); } }现在我想在createOrder方法前后加日志不修改原始类只做一层包装import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; public class JdkProxyDemo { public static void main(String[] args) { OrderService target new OrderServiceImpl(); OrderService proxy (OrderService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), new InvocationHandler() { Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println(【前置增强】准备创建订单); Object result method.invoke(target, args); System.out.println(【后置增强】订单创建完成); return result; } } ); proxy.createOrder(NO-10001); } }运行后输出【前置增强】准备创建订单 创建订单NO-10001 【后置增强】订单创建完成这里的关键只有三件事Proxy.newProxyInstanceJVM 在运行时动态生成一个代理类。第二个参数target.getClass().getInterfaces()代理类需要实现的接口列表。InvocationHandler.invoke所有接口方法被调用时都会进到这个统一入口。这个模式理解起来很像一个“外包客服中心”。你打电话调用方法到总机代理对象总机不会直接处理而是转给客服专员InvocationHandler客服专员按照流程记录工单前置增强再转给真正干活的人目标对象干完再回访后置增强。2.2 为什么 JDK 代理死守接口这个门槛这是面试必问的一道题为什么 JDK 动态代理的前提是目标类必须有接口答案要从 Java 的单继承限制说起。JVM 在运行时替你生成的代理类默认已经继承了java.lang.reflect.Proxy这个类。既然 Java 只允许单继承代理类就不可能再去继承你的OrderServiceImpl。所以它想“冒充”你的目标对象唯一能走的路就是和你的目标类实现同一个接口。这样调用方拿到的OrderService引用既可以是原始实现类也可以是代理类多态保证了两者互换。你想想看如果目标类根本没有接口代理类就不知道该以什么“身份”出现在代码里。你总不能把代理类塞进一个Object引用里然后让调用方还像原来一样点出createOrder方法吧编译器根本不知道代理类有没有这个方法。所以JDK 动态代理的适用公式就是目标类型必须作为接口公开调用方走接口编程代理类才能顺理成章地顶替上去。2.3 JDK 代理的三条边界线我在真实项目里总结出三条实际限制很多时候不是不能用 JDK 代理而是你设计类的时候根本不满足条件没有接口的类JDK 代理直接没辙。就算你拿到类对象也构造不出代理。代理对象只能强转为接口类型转回实现类会抛异常。如果你在代码里写着(OrderServiceImpl) proxy运行时会报ClassCastException。因为代理类并不是OrderServiceImpl的子类。只有接口里声明的方法能被代理拦截。如果实现类自己有个extraMethod()但接口没声明那么通过代理对象根本调不到这个方法更谈不上增强。这第三条非常容易踩坑。以前我接手过一个老项目Service 里为了方便写了一个queryUserById方法但接口里没定义。之前所有代码都是直连实现类引用好好的后来有人给方法加了事务注解却发现事务完全无效就是因为这些私有/非接口方法从来没有被代理过。3. CGLIB用字节码“复印”出一个代理类3.1 CGLIB 的运行机制CGLIBCode Generation Library走的是完全不同的路子。它不管你有没有接口直接为你的类生成一个子类通过重写非final方法来实现代理。还是刚才那个例子我把OrderServiceImpl改成没有接口的类CGLIB 一样能代理public class OrderService { public void createOrder(String orderNo) { System.out.println(创建订单 orderNo); } }使用 CGLIB 的方式import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; public class CglibProxyDemo { public static void main(String[] args) { OrderService target new OrderService(); Enhancer enhancer new Enhancer(); enhancer.setSuperclass(target.getClass()); enhancer.setCallback(new MethodInterceptor() { Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { System.out.println(【前置增强】准备创建订单); Object result proxy.invokeSuper(obj, args); System.out.println(【后置增强】订单创建完成); return result; } }); OrderService proxy (OrderService) enhancer.create(); proxy.createOrder(NO-10001); } }注意这里面的MethodProxy.invokeSuper(obj, args)它直接调用父类也就是目标类的原方法而不是像 JDK 代理那样通过method.invoke(target, args)绕一圈反射。这一步对性能的影响非常关键。CGLIB 的底层用的是 ASM 来生成字节码。它展开来其实做了这样几件事读取目标类的字节码结构。动态生成一个新的子类。在子类中重写目标类所有非final的、非static的、非private的方法。重写的方法体里插入对MethodInterceptor的回调。3.2 CGLIB 真的不需要接口吗严格说CGLIB 不要求接口但 CGLIB 也不排斥接口。如果你给Enhancer同时指定了父类和接口生成的代理子类照样可以实现这些接口。所以“CGLIB 不需要接口”这句话准确的理解应该是接口对 CGLIB 来说是可选项不是一个必要条件。这里穿插一个很多人没意识到的问题Spring 里如果一个 Bean 没有实现任何接口Spring 会用 CGLIB 代理如果 Bean 实现了接口但你在配置里强制proxyTargetClasstrueSpring 也会用 CGLIB。强制走 CGLIB 之后代理类会同时继承目标类并实现目标接口所以它能被强转为接口引用也能被强转为具体实现类引用灵活度比 JDK 代理高。3.3 FastClassCGLIB 性能优势的秘密武器CGLIB 的动态性能之所以通常优于 JDK 代理除了早期的 JDK 代理在反射调用上开销更大之外更重要的是 CGLIB 引入了 FastClass 机制。MethodProxy在调用invokeSuper时并不是用传统反射去执行的。CGLIB 会为目标类专门生成一个索引类FastClass把方法调用编成整数索引直接根据索引在生成的字节码里跳转执行。这个机制有点像什么有点像你把经常用的电话号码存成快捷键按一个数字就直接拨出去了不用再翻通讯录一个字母一个字母找。在 JDK 代理的InvocationHandler里method.invoke(target, args)是一个完整的反射调用过程需要做可见性检查、参数匹配、安全检查等等这些都有额外开销。所以很长一段时间里业内都说 CGLIB 的动态代理执行效率优于 JDK 代理。后来 JDK 对反射做了大量优化比如反射缓存、方法句柄差距在缩小但 CGLIB 的 FastClass 机制依然是一个无法忽视的优势。3.4 CGLIB 的三个硬伤CGLIB 也不是万能的这三个硬伤我在项目里都撞见过目标类不能是final的。父类都得final了子类没法继承。final方法无法被代理。CGLIB 继承之后重写不了final方法调用直接落到原方法上增强不会触发。构造器会被调用。CGLIB 通过继承生成代理创建代理对象时会先调用父类的构造器。如果目标类构造器里有比较重的逻辑比如初始化连接池、访问外部资源那每次创建 CGLIB 代理时都会连带执行一次这在某些场景下是明显的副作用。更重要的是如果目标类没有无参构造器Enhancer需要额外指定构造器参数类型否则会报错。经常有同学抱怨“我的 Bean 是 abstractCGLIB 能代理吗”也能因为 CGLIB 生成的是抽象类的子类只要方法不是final照样能代理。但 Spring 一般不会去代理抽象类这个更多是测试里的用法。4. Spring 背后的选择逻辑从默认 JDK 到默认 CGLIB 的演变4.1 Spring AOP 的代理工厂决策流程Spring 从DefaultAopProxyFactory开始决定创建一个 AOP 代理时核心逻辑是这样的public AopProxy createAopProxy(AdvisedSupport config) throws AopConfigException { if (config.isOptimize() || config.isProxyTargetClass() || hasNoUserSuppliedProxyInterfaces(config)) { Class? targetClass config.getTargetClass(); if (targetClass.isInterface() || Proxy.isProxyClass(targetClass)) { return new JdkDynamicAopProxy(config); } return new ObjenesisCglibAopProxy(config); } else { return new JdkDynamicAopProxy(config); } }翻译成人话如果目标类本身就是接口或者目标类已经是 JDK 代理类那就继续用 JDK 动态代理。如果目标类没有实现任何用户自定义的接口那就用 CGLIB。如果配置了proxyTargetClasstrue直接走 CGLIB。有了这个决策逻辑你就可以理解很多反常现象了。比如你给一个实现了接口的 Service 加事务发现日志打印里关联到的是OrderService$$EnhancerBySpringCGLIB$$...而不是$Proxy...。这多半是你在某处全局配置了spring.aop.proxy-target-classtrue或者是项目里用了 Spring Boot 的自动配置它默认就开了这个开关。4.2 Spring Boot 2.x 之后为什么“倒向”CGLIB老项目如果是 Spring Boot 1.x 时代创建的你可能还记得默认代理方式是 JDK 动态代理。当一个 Bean 实现了接口Spring 默认就生成 JDK 代理你必须在application.properties里手动写spring.aop.proxy-target-classtrue才会切换成 CGLIB。但在 Spring Boot 2.0 时代官方直接把spring.aop.proxy-target-class的默认值改成了true。理由其实很现实JDK 代理要求你代码里全部面向接口编程但现实中很多老代码直接注入实现类一旦被 JDK 代理后强转回去就ClassCastException。Spring 容器自动装配、事务管理、定时任务等场景都希望代理之后还能兼容具体的实现类类型CGLIB 的继承方式能更好地兜底。这个变更对使用者来说是很痛的。很多老项目从 Boot 1.x 升到 2.x什么都不改突然出现一堆“Bean 不是预期类型”或者切面不生效的问题。本质上就是代理生成路线变了类型体系也变了。4.3 什么情况下你还需要手动指定 proxyTargetClass虽然 Spring Boot 默认走 CGLIB但手动配置还是有用武之地的。常见的场景你明确希望用 JDK 代理来保证代码风格和依赖注入都走接口方便做 Mock 和测试。某些第三方库对 CGLIB 生成的类不友好比如一些序列化框架遇到 CGLIB 生成的类会出问题。目标类有特殊构造器或者final限制CGLIB 代理直接失败你必须退回 JDK 代理。配置方式Configuration EnableAspectJAutoProxy(proxyTargetClass false) public class AppConfig { }或者在 Spring Boot 里spring.aop.proxy-target-classfalse这里要注意如果你用了Transactional它走的也是 AOP 代理机制所以这个开关同样会影响事务代理的生成方式。4.4 三个带“接口”的意外场景有些情况虽然实现了接口但不走接口代理。我用表格整理一下场景实际代理方式原因Configuration类CGLIB 代理Spring 需要拦截Bean方法实现单例语义被Repository标注的类取决于接口情况标准 AOP 决策Async注解的 Bean默认 CGLIBSpring Boot 全局配置 代理模式通过ProxyFactory手动配置可显式指定完全控制Configuration类为什么必须 CGLIB因为 Spring 在解析配置类时需要让一个Bean方法调用另一个Bean方法时返回同一个单例实例而不是新建一个。这必须通过子类拦截来实现JDK 代理没法对非接口的类方法做拦截。5. 实战中的“变脸”翻车现场五个高频坑与排查思路到这里原理基本讲完了。下面进入我认为最值钱的部分——这些坑是真的会写在代码里、然后花掉你半个晚上排查的那种。5.1 坑一同类内部方法调用代理彻底失效这是我在文首提到的问题也是 Spring AOP 代理失效最高频的一种。Service public class OrderServiceImpl implements OrderService { Transactional public void createOrder(String orderNo) { updateStock(orderNo); } Transactional(propagation Propagation.REQUIRES_NEW) public void updateStock(String orderNo) { // 扣减库存 } }createOrder被外部调用时进来的调用方拿着的是代理对象。但代理对象执行createOrder()方法体时里面的updateStock(orderNo)是this.updateStock(...)这个this是目标对象本身不是代理对象所以Transactional在这里失效。这句话值得再读一遍代理只对“从外部进入代理对象”的调用生效代理对象内部、目标对象自身的方法调用是绕开代理的。解决办法我实际用下来有三种注入自身代理对象Autowired Lazy private OrderService self; public void createOrder(String orderNo) { self.updateStock(orderNo); }拆分类把updateStock放到另一个 Service 里。使用AopContext.currentProxy()但要求启动时配置exposeProxytrue((OrderService) AopContext.currentProxy()).updateStock(orderNo);第 3 种不推荐在业务代码里用读起来很丑而且currentProxy拿不到的时候会抛异常调试成本高。5.2 坑二final/static/private方法增强不生效这三种方法在不同层面被挡在代理之外finalCGLIB 无法重写JDK 代理则根本不关心。static不属于实例调用代理类无法通过多态拦截。private方法调用是静态绑定根本不参与动态分派。实际表现就是你的切点明明写了这个方法但它就是不打日志。如果你正在排查这种问题先看一眼方法的修饰符是不是里面混了private。有些同学写辅助方法习惯性加private结果切到私人方法上自然是失效的。5.3 坑三CGLIB 代理无法应用于 final 类一个final class ServiceSpring 不管怎么配 CGLIB 都无能为力。启动阶段通常会看到类似Cannot subclass final class com.example.Service处理思路是什么要么去掉final要么强制 Spring 用 JDK 代理前提是类实现了接口。如果你在设计类时就知道这个类会被 AOP 增强避免把它声明成final这是一个经验教训。5.4 坑四CGLIB 父类没有无参构造器CGLIB 生成子类时默认会调用父类的无参构造器。如果目标类只有带参构造器而你又没通过Enhancer的构造器参数配置告诉它怎么调用就会报NoSuchMethodError或者类似错误。Spring 的ObjenesisCglibAopProxy实际上绕过了构造器来创建对象所以 Spring 场景下这个坑相对少见。但如果你脱离 Spring直接手写 CGLIB 代理来包一层已有类就会踩到。5.5 坑五代理对象与目标对象不是一个类型序列化/JSON 输出翻车CGLIB 代理类会多出一堆合成字段比如CGLIB$CALLBACK_0、CGLIB$BOUND等等。如果你的接口返回的是代理对象然后直接通过 Jackson 序列化某些版本下可能会把底层回调也一起序列化产生循环引用或者巨长 JSON。解决办法通常是在实体/DTO 里不要直接返回代理对象而是先转成普通对象或者给相关字段加JsonIgnoreProperties。这里的问题本质是方法代理是运行期的行为但数据载体应该保持纯洁。6. 面试官想听到的答案一个足够深入的总结角度我不能免俗最后聊一个面试里最常被问到的问题。不是要你背标准答案而是帮你理解面试官到底在考察什么。“Spring AOP 用的是 JDK 动态代理还是 CGLIB”这个问题的正确答案不是“JDK”或“CGLIB”而是看条件。在 Spring Framework 5.x / Spring Boot 2.x 之前有接口默认 JDK 代理Spring Boot 2.x 之后默认proxyTargetClasstrue所以大多数场景是 CGLIB。但底层决策逻辑还是要回到DefaultAopProxyFactory那段代码。更好的回答方式是多走一步“JDK 动态代理要求目标类有接口利用Proxy.newProxyInstance生成实现同一接口的代理类通过InvocationHandler统一拦截方法调用CGLIB 通过生成目标类的子类来代理不需要接口能处理更多没有接口的类通过MethodInterceptor和MethodProxy来增强。Spring Boot 2.x 之后默认使用 CGLIB主要是为了解决类型兼容性和自引用的问题。”然后你再补充几个实际场景里的细节比如说“同类内部调用会让代理失效”“final方法无法被 CGLIB 增强”“MethodProxy.invokeSuper走的是 FastClass 索引而不是传统反射”面试官基本就能判断你不是背题是真的在项目里写过代理。我个人的体会是动态代理这两条技术路线怎么强调都不为过。一个 Java 程序员可能很多年都在用 Spring 却不写一行代理代码但理解代理是理解 Spring AOP、事务传播、Configuration单例语义、异步方法、缓存切面这些高级特性的底层地基。遇到相关 bug 时这个地基能让你少走很多弯路。如果你看完觉得还有点绕建议手动跑一遍上面的例子再仔细看一遍 Spring 源码里DefaultAopProxyFactory的判定逻辑比背十遍面经都管用。
 非阻塞任务）)
