Spring 源码系列(14): JDK 动态代理 vs CGLIB,以及拦截器责任链

发布时间:2026/8/3 16:58:49
Spring 源码系列(14): JDK 动态代理 vs CGLIB,以及拦截器责任链 阅读前提示AOP 阶段的收官篇。前两篇我们走通了「BPP 在初始化后调用wrapIfNecessary → createProxy」。本篇回答最后两个硬核问题1代理类型怎么选2一次方法调用时多个通知是怎么「排着队」依次执行的并彻底讲清「同类自调用 AOP 失效」的底层原因。一、引子为什么面试必问 JDK 还是 CGLIB因为这背后藏着 Spring 对「性能 / 兼容性 / 能力边界」的取舍JDK 动态代理基于接口生成实现类要求目标必须实现接口调用快、但不能代理类本身的方法非接口方法切不到。CGLIB基于继承生成子类重写方法能代理普通类无需接口但不能代理 final 类 / final 方法且生成字节码略慢。Spring 的DefaultAopProxyFactory就是在这两者间做裁决。二、源码追踪一代理类型裁决逻辑// DefaultAopProxyFactory.javaOverridepublicAopProxycreateAopProxy(AdvisedSupportconfig)throwsAopConfigException{// optimize激进优化proxyTargetClass强制 CGLIBisProxyTargetClassif(config.isOptimize()||config.isProxyTargetClass()||hasNoUserSuppliedProxyInterfaces(config)){Class?targetClassconfig.getTargetClass();if(targetClassnull)thrownewAopConfigException(TargetSource 无法确定目标类);// 目标类是接口或已经是 JDK 代理类 → 只能用 JDK 动态代理if(targetClass.isInterface()||Proxy.isProxyClass(targetClass)){returnnewJdkDynamicAopProxy(config);}// 其余 → CGLIBreturnnewObjenesisCglibAopProxy(config);}else{// 没强制 CGLIB且有用户提供的接口 → JDK 动态代理returnnewJdkDynamicAopProxy(config);}}2.1 裁决规则一览表条件结果proxyTargetClasstrue或 Boot 默认CGLIBoptimizetrueCGLIB目标类无接口、且非强制 JDKCGLIB目标类实现了接口、且proxyTargetClassfalseJDK 动态代理目标类是接口本身 / 已是 JDK 代理强制JDK 动态代理⚠️ 易错点「有接口就一定用 JDK 代理」——错。只要proxyTargetClasstrueBoot 默认就是即使有接口也走 CGLIB。规则优先级是强制 CGLIB 配置 接口存在。三、源码追踪二调用时的拦截器责任链无论哪种代理最终调用都会进入「责任链」。以 JDK 代理为例3.1 JdkDynamicAopProxy.invoke 织入责任链// JdkDynamicAopProxy.javaOverridepublicObjectinvoke(Objectproxy,Methodmethod,Object[]args)throwsThrowable{// ① 取出该方法的拦截器链已按 Order 排序ListObjectchainthis.advised.getInterceptorsAndDynamicInterceptionAdvice(method,targetClass);if(chain.isEmpty()){// ② 无通知 → 直接反射调用目标方法不走代理逻辑returnAopUtils.invokeJoinpointUsingReflection(target,method,args);}// ③ 包装成 MethodInvocation递归推进责任链MethodInvocationinvocationnewReflectiveMethodInvocation(proxy,target,method,args,targetClass,chain);returninvocation.proceed();// ← 责任链启动}3.2 ReflectiveMethodInvocation.proceed递归式「逐个执行」// ReflectiveMethodInvocation.javaOverridepublicObjectproceed()throwsThrowable{if(this.currentInterceptorIndexthis.interceptorsAndDynamicMethodMatchers.size()-1){// 链走完 → 调用真实目标方法returninvokeJoinpoint();}ObjectinterceptorOrInterceptionAdvicethis.interceptorsAndDynamicMethodMatchers.get(this.currentInterceptorIndex);if(interceptorOrInterceptionAdviceinstanceofMethodInterceptor){MethodInterceptormi(MethodInterceptor)interceptorOrInterceptionAdvice;returnmi.invoke(this);// ← 每个拦截器处理完后再调 proceed() 推进下一个}// 动态匹配拦截器returnproceed();} 责任链本质这是经典的「递归 索引推进」。Around对应的MethodInterceptor.invoke(this)内部会调用invocation.proceed()进入下一个拦截器当所有拦截器走完才执行真实目标方法。出栈顺序天然形成「环绕」效果。3.3 通知执行顺序单切面前通知在链路中的位置执行特点Aroundproceed 之前最外最先执行包住一切Before靠前proceed 前打印/校验目标方法链底invokeJoinpoint()AfterReturning返回后拿到返回值Afterfinally必执行AfterThrowing异常分支仅异常时Aroundproceed 之后最外返回最后收尾四、终极问题同类自调用为什么 AOP 失效ServicepublicclassOrderService{publicvoidcreate(){this.validate();// ← this 指向【原始对象】不是代理}Transactionalpublicvoidvalidate(){/* ... */}}原因create()是由代理对象调入的但方法体内的this是原始目标对象Spring 注入的是原始 Bean代理只是外层壳。this.validate()绕过了代理责任链根本没机会执行Transactional/ 切面全部失效。两种解法// 解法一exposeProxytrue 后从 AopContext 取代理再调EnableAspectJAutoProxy(exposeProxytrue)publicclassAopConfig{}publicvoidcreate(){((OrderService)AopContext.currentProxy()).validate();// 走代理AOP 生效}// 解法二拆到另一个 Bean推荐解耦更清晰AutowiredOrderValidatorvalidator;publicvoidcreate(){validator.validate();}// 跨 Bean 调用代理正常介入 结论自调用失效的根因是「代理是包装不是替换」——this永远是原始对象。理解这点所有「AOP 没生效」的诡异问题都能定位。五、常见误区误区正解有接口就一定 JDK 代理错proxyTargetClasstrue时强制 CGLIBCGLIB 不能代理任何类只能代理非 final 类、非 final 方法Around不调 proceed 也能返回不调 proceed 目标不执行需自己定返回值自调用时 AOP 也生效失效因this指向原始对象见第四节无匹配通知的 Bean 走代理也慢空链直接反射调目标几乎无开销 面试题自测DefaultAopProxyFactory选 JDK 还是 CGLIB 的完整规则为什么proxyTargetClasstrue时即使有接口也走 CGLIBReflectiveMethodInvocation.proceed()的递归推进原理同类自调用 AOP 失效的根因两种解法CGLIB 代理有什么限制final / 构造器等为什么Around能完全控制目标方法是否执行 Debug 小技巧在JdkDynamicAopProxy.invoke断点观察chain列表的元素顺序对应通知执行顺序再单步进入ReflectiveMethodInvocation.proceed用「Step Over 走到mi.invoke(this)、再 Step Into」的方式逐拦截器感受责任链的递归推进。最后在create()里加this AopContext.currentProxy()的条件断点亲眼看到「自调用时两边不等」。下一篇预告AOP 阶段完结。下一篇进入Spring MVC 阶段第 15 篇DispatcherServlet如何初始化——onRefresh → initStrategies九大组件以及一次 HTTP 请求在 Spring 里的「总调度」是如何搭起来的。如果这篇对你有帮助欢迎点赞 · 收藏 · 关注三连支持。Spring 源码系列共 30 篇由浅入深持续更新中。有疑问或想深挖的源码点评论区告诉我下篇见。