1. 为什么动态代理值得单独拎出来聊做 Java 的人迟早会撞上动态代理这个东西。你可能在面试八股文里背过“JDK 动态代理基于接口CGLIB 基于继承”也可能在 Spring 的 AOP 里用过Transactional、Async但真要自己手写一个代理逻辑或者排查“为什么我的切面没生效”“为什么这个 Bean 注入的是个 Proxy 对象”时很多人就卡壳了。动态代理不是一个孤立的语法点它是 Spring AOP、MyBatis 的 Mapper 接口、RPC 框架客户端 stub、各类注解驱动框架的底层地基。你把它吃透看框架源码时那种“雾里看花”的感觉会少一大半。这篇文章面向的是已经会写 Java、能看懂反射基础 API但对动态代理只停留在“背概念”阶段的开发者。我会从“为什么需要它”讲起把 JDK 动态代理和 CGLIB 两条路线拆开揉碎配上能直接跑起来的代码再聊聊实际项目里那些文档不会写的坑。全程不堆砌术语遇到复杂的地方就用生活化的类比兜底目标是让你读完能自己动手写一个简易的 AOP 或者一个接口代理工厂。先说清楚一个前提动态代理的核心价值在于在不修改目标类源码的前提下对方法调用进行拦截和增强。静态代理你得为每个目标类手写一个代理类类一多就是灾难动态代理则是运行时生成代理类一套拦截逻辑可以套用到无数个目标上。这个“运行时生成”的能力靠的是反射和字节码操作理解这一点后面所有细节都能串起来。2. 动态代理到底解决了什么问题2.1 从静态代理的痛点说起假设你有一个用户服务接口UserService里面有个saveUser方法。现在产品要求每次保存用户前后打日志、开事务、做权限校验。最笨的办法是直接改UserService的实现类把日志和事务代码硬编码进去。但这样业务代码就被非业务逻辑污染了而且如果十个 Service 都要加同样的逻辑你得改十遍。静态代理的思路是写一个UserServiceProxy它持有真实的UserService实例在调用真实方法前后插入增强逻辑。这确实解耦了但问题也很明显——每个接口都要配一个代理类。系统里有 50 个 Service你就得写 50 个代理类改一次增强逻辑要动 50 个文件。这就是静态代理的死穴代理类和目标类是一一绑定的无法复用。动态代理把“写代理类”这件事从编译期挪到了运行期。你只需要写一份拦截逻辑比如一个InvocationHandlerJVM 在运行时帮你生成代理类。目标类有多少个都无所谓一份逻辑通吃。这就是它存在的根本理由。2.2 动态代理在主流框架里的真实身影很多人以为动态代理是个“面试专用”的知识点其实它无处不在。Spring AOP 默认对实现了接口的 Bean 用 JDK 动态代理对没有接口的 Bean 用 CGLIBMyBatis 的 Mapper 接口你只写了接口没写实现运行时能注入进来靠的就是 JDK 动态代理生成的代理对象Dubbo、Feign 这类 RPC 框架客户端调用远程服务时拿到的也是一个代理对象方法调用被拦截后转成网络请求发出去。理解了这个背景你就明白为什么面试官爱问它——它不是孤立的 API 用法而是检验你是否理解框架底层运作方式的一块试金石。你答得出“JDK 代理为什么必须基于接口”往往意味着你理解Proxy.newProxyInstance生成的类默认继承了Proxy类而 Java 是单继承的所以只能靠接口来约束行为。2.3 两条技术路线的本质差异动态代理在 Java 世界里主要有两条实现路径。一条是 JDK 自带的位于java.lang.reflect包下核心是Proxy类和InvocationHandler接口另一条是第三方字节码库 CGLIB核心是Enhancer类和MethodInterceptor接口。JDK 路线的约束是目标类必须实现至少一个接口因为生成的代理类要继承Proxy并实现这些接口。CGLIB 路线则是通过继承目标类、覆写其方法来生成子类所以它不要求接口但要求目标类和方法不能是final的。两者没有绝对的优劣Spring 的策略是“有接口用 JDK没接口用 CGLIB”这个选择背后是对兼容性和性能的综合权衡后面会细讲。3. JDK 动态代理从一行代码到运行原理3.1 最小可运行示例先上一段能直接复制运行的代码建立直观感受。定义一个接口和实现类public interface OrderService { void createOrder(String orderId); String queryOrder(String orderId); } public class OrderServiceImpl implements OrderService { Override public void createOrder(String orderId) { System.out.println(创建订单: orderId); } Override public String queryOrder(String orderId) { return 订单详情- orderId; } }然后写一个InvocationHandler这是所有增强逻辑的入口import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; public class LogHandler implements InvocationHandler { private final Object target; public LogHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { System.out.println([前置] 调用方法: method.getName()); long start System.currentTimeMillis(); Object result method.invoke(target, args); long cost System.currentTimeMillis() - start; System.out.println([后置] 方法 method.getName() 耗时 cost ms); return result; } }最后生成代理并调用import java.lang.reflect.Proxy; public class Main { public static void main(String[] args) { OrderService target new OrderServiceImpl(); OrderService proxy (OrderService) Proxy.newProxyInstance( target.getClass().getClassLoader(), target.getClass().getInterfaces(), new LogHandler(target) ); proxy.createOrder(ORD-001); String detail proxy.queryOrder(ORD-001); System.out.println(返回结果: detail); } }跑起来你会看到前置日志、真实方法输出、后置耗时日志依次打印。注意proxy这个对象的类型是OrderService但它的实际类名是com.sun.proxy.$Proxy0这种运行时生成的类。你可以加一行proxy.getClass().getName()打印出来看看这个细节在排查问题时很有用。3.2 InvocationHandler 里三个参数的门道invoke方法的三个参数各有讲究很多人用的时候只关注method和args忽略了proxy其实它藏着坑。第一个参数proxy是生成的代理对象本身。这里有个经典陷阱如果你在invoke里写proxy.toString()或者把proxy传给别人再调用它的方法会再次触发invoke形成无限递归最后StackOverflowError。正确做法是调用target上的方法而不是proxy上的。我见过有人在日志里打印proxy对象结果日志框架调用proxy.toString()直接栈溢出排查了半天。第二个参数method是当前被调用的方法对象。通过它你能拿到方法名、参数类型、返回类型、注解信息。比如判断方法上有没有某个自定义注解就可以用method.isAnnotationPresent(MyAnnotation.class)。这是实现注解驱动增强的关键。第三个参数args是调用时传入的实参数组。如果方法没有参数这个值是null而不是空数组直接遍历会 NPE得先判空。这个细节文档里不显眼但实际写拦截逻辑时经常踩。3.3 生成的代理类长什么样Proxy.newProxyInstance在运行时生成的类结构大致是这样的伪代码public final class $Proxy0 extends Proxy implements OrderService { private static Method m3; // createOrder private static Method m4; // queryOrder public $Proxy0(InvocationHandler h) { super(h); } Override public final void createOrder(String orderId) { try { super.h.invoke(this, m3, new Object[]{orderId}); } catch (Throwable e) { throw new UndeclaredThrowableException(e); } } Override public final String queryOrder(String orderId) { try { return (String) super.h.invoke(this, m4, new Object[]{orderId}); } catch (Throwable e) { throw new UndeclaredThrowableException(e); } } }看几个关键点代理类继承Proxy所以它不能再继承别的类这就是“JDK 代理必须基于接口”的根本原因方法都是final的所以你不能再去覆写所有方法调用最终都转发给h.invokeh就是你传入的InvocationHandler。理解了这个结构很多行为就顺理成章了——比如为什么代理对象不能强转成目标实现类因为它和OrderServiceImpl是兄弟关系都实现了OrderService但没有继承关系。3.4 一个容易忽略的细节equals、hashCode、toString生成的代理类除了接口方法还会代理equals、hashCode、toString这三个来自Object的方法。也就是说当你调用proxy.equals(x)时也会走invoke。如果你在invoke里没做特殊处理直接method.invoke(target, args)那equals比较的是target和x而不是proxy和x语义上可能不符合预期。更麻烦的是toString前面说的递归陷阱就出在这里。稳妥的做法是在invoke开头判断方法归属if (method.getDeclaringClass() Object.class) { return method.invoke(target, args); }这样equals、hashCode、toString就直接委托给目标对象不进入你的增强逻辑既避免了递归也符合大多数场景的语义预期。这个处理在写通用代理工厂时几乎是标配但很多教程不会提。4. CGLIB没有接口时的另一条路4.1 为什么需要 CGLIBJDK 动态代理的硬约束是“必须有接口”。但现实项目里很多类就是没有接口的比如一些工具类、配置类或者历史遗留代码。这时候 JDK 代理就无能为力了。CGLIB 的思路完全不同它不要求接口而是通过字节码技术动态生成一个目标类的子类覆写父类的非 final 方法在子类里插入拦截逻辑。打个比方JDK 代理像是给一个“接口契约”找了个替身替身和真身都遵守同一份契约CGLIB 代理则是给真身生了个“儿子”儿子继承了父亲的所有本事但每个本事都偷偷加了料。所以 CGLIB 的限制也很明确目标类不能是final的final 类没法被继承目标方法不能是final的final 方法没法被覆写私有方法也代理不了。4.2 最小可运行示例CGLIB 需要引入依赖Maven 里加dependency groupIdcglib/groupId artifactIdcglib/artifactId version3.3.0/version /dependency注意 Spring 从 3.2 开始把 CGLIB 的类重新打包进了spring-core包名变成了org.springframework.cglib如果你在 Spring 项目里用不需要单独引依赖直接用 Spring 重打包的版本即可避免版本冲突。写一个没有接口的目标类public class PaymentService { public void pay(String userId, double amount) { System.out.println(用户 userId 支付 amount 元); } }用Enhancer生成代理import org.springframework.cglib.proxy.Enhancer; import org.springframework.cglib.proxy.MethodInterceptor; import org.springframework.cglib.proxy.MethodProxy; import java.lang.reflect.Method; public class CglibDemo { public static void main(String[] args) { Enhancer enhancer new Enhancer(); enhancer.setSuperclass(PaymentService.class); enhancer.setCallback(new MethodInterceptor() { Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { System.out.println([CGLIB 前置] method.getName()); Object result proxy.invokeSuper(obj, args); System.out.println([CGLIB 后置] method.getName()); return result; } }); PaymentService proxy (PaymentService) enhancer.create(); proxy.pay(U1001, 99.9); } }这里有个关键区别MethodInterceptor的intercept方法比 JDK 的invoke多了一个MethodProxy参数。调用真实方法时用的是proxy.invokeSuper(obj, args)而不是method.invoke(target, args)。为什么因为 CGLIB 生成的子类里obj本身就是代理对象invokeSuper会直接调用父类也就是目标类的原始方法绕过了拦截器避免了递归。而method.invoke需要你持有目标实例CGLIB 的用法里通常不持有目标实例所以走invokeSuper更自然。4.3 invokeSuper 和 invoke 的区别MethodProxy提供了两个方法invokeSuper和invoke。前者调用的是父类方法后者调用的是指定对象上的方法。在标准拦截器写法里必须用invokeSuper因为obj是代理对象用invoke(obj, args)会再次触发拦截器死循环。这个坑我踩过。当时图省事写了proxy.invoke(obj, args)结果一调用就栈溢出日志刷了几千行才崩。后来看源码才明白invoke走的是普通反射调用会命中代理类覆写的方法而invokeSuper走的是 CGLIB 生成的快速调用通道直接定位到父类方法。性能上invokeSuper也更好因为它避免了反射的开销。4.4 CGLIB 的性能与兼容性权衡早期有种说法是“CGLIB 比 JDK 代理快”这个结论要分场景。CGLIB 生成代理类的过程比 JDK 慢字节码生成开销大但代理类生成后方法调用的性能通常优于 JDK 反射。不过在 JDK 8 之后JDK 动态代理的性能有了明显优化两者差距已经不大。Spring 的默认策略是“有接口用 JDK没接口用 CGLIB”这个选择更多是出于兼容性考虑而不是单纯拼性能。兼容性方面CGLIB 因为要生成子类遇到final类、final方法、私有构造函数的类就会失败。Spring Boot 2.x 之后默认把spring.aop.proxy-target-class设为true也就是强制用 CGLIB原因之一是避免“同一个类有时被代理成接口类型、有时被代理成实现类型”导致的类型转换异常。这个默认值的变化很多老项目升级时会踩坑比如某个 Bean 依赖注入时按实现类类型注入JDK 代理下会失败切到 CGLIB 就好了。5. 手写一个通用代理工厂5.1 设计思路理解了两种代理的用法我们来写一个通用工厂根据目标类是否实现接口自动选择代理方式。这个练习能帮你把前面的知识点串起来也是很多框架内部做的事。核心逻辑是如果目标类实现了接口用 JDK 代理否则用 CGLIB。增强逻辑统一抽象成一个接口让调用方传入。public interface MethodAdvice { Object before(Object target, Method method, Object[] args); Object after(Object target, Method method, Object[] args, Object result); }5.2 JDK 分支的实现public class JdkProxyFactory { public static Object create(Object target, MethodAdvice advice) { Class? clazz target.getClass(); return Proxy.newProxyInstance( clazz.getClassLoader(), clazz.getInterfaces(), (proxy, method, args) - { if (method.getDeclaringClass() Object.class) { return method.invoke(target, args); } advice.before(target, method, args); Object result method.invoke(target, args); return advice.after(target, method, args, result); } ); } }5.3 CGLIB 分支的实现public class CglibProxyFactory { public static Object create(Object target, MethodAdvice advice) { Enhancer enhancer new Enhancer(); enhancer.setSuperclass(target.getClass()); enhancer.setCallback((MethodInterceptor) (obj, method, args, proxy) - { advice.before(target, method, args); Object result proxy.invokeSuper(obj, args); return advice.after(target, method, args, result); }); return enhancer.create(); } }注意 CGLIB 分支里before和after传的是target而不是obj因为obj是代理对象传出去可能引发递归。这个细节在写通用组件时很重要。5.4 统一入口与选择逻辑public class ProxyFactory { public static Object createProxy(Object target, MethodAdvice advice) { Class? clazz target.getClass(); if (clazz.getInterfaces().length 0) { return JdkProxyFactory.create(target, advice); } return CglibProxyFactory.create(target, advice); } }这个工厂虽然简陋但骨架和 Spring 的DefaultAopProxyFactory是一致的。你可以基于它扩展出注解驱动的切面、方法级缓存、重试逻辑等等。写一遍之后再看 Spring 的JdkDynamicAopProxy和CglibAopProxy源码会发现思路完全对得上。6. 实际项目里的坑与排查技巧6.1 常见问题速查表问题现象可能原因排查方向切面不生效目标类没有接口且未开启 CGLIB检查proxy-target-class配置注入时类型转换异常JDK 代理生成的是接口类型按接口注入或强制 CGLIB调用代理方法栈溢出invoke 里调用了 proxy 自身方法检查是否误用 proxy 而非 targetCGLIB 代理失败目标类是 final 或方法 final去掉 final 或改用接口事务注解失效同类内部方法调用不走代理拆分方法或注入自身代理代理对象 toString 异常未处理 Object 方法invoke 开头判断 declaringClass6.2 同类内部调用导致切面失效这是 Spring AOP 里最经典的坑。假设OrderServiceImpl里有个methodA调用了同类的methodB而methodB上标了Transactional。你从外部调用methodA会发现methodB的事务没生效。原因是外部调用走的是代理对象代理对象调用methodA时进入增强逻辑但methodA内部调用methodB用的是this也就是目标对象本身不经过代理自然不触发增强。解决办法有三种一是把methodB挪到另一个 Bean 里二是注入自身代理Autowired private OrderService self;然后self.methodB()三是用AopContext.currentProxy()拿到当前代理。第一种最干净后两种在特定场景下用。这个坑几乎每个用 Spring 的人都踩过面试也爱问。6.3 代理对象的类型判断陷阱用 JDK 代理时proxy instanceof OrderServiceImpl是false因为代理类只实现了接口没有继承实现类。如果你在代码里写了这种判断逻辑就会出错。正确做法是判断接口类型proxy instanceof OrderService。这个问题在事件监听、类型分发场景里特别容易翻车因为运行时你拿到的是一个Object想根据具体类型做不同处理结果判断全落空。6.4 序列化与代理对象的兼容性如果代理对象需要被序列化比如放进缓存、通过 RPC 传输JDK 代理生成的类名是$Proxy0这种反序列化时如果目标环境没有对应的接口和InvocationHandler就会失败。CGLIB 代理的子类同样有类似问题。实际项目里跨进程传输的通常是数据对象而不是代理对象但如果你不小心把代理对象塞进了 Session 或者缓存排查起来会很头疼。经验是代理对象只在容器内部流转不要让它跨越序列化边界。7. 面试高频问题与答题思路7.1 JDK 动态代理为什么必须基于接口这个问题的标准答案是Proxy.newProxyInstance生成的代理类默认继承java.lang.reflect.Proxy而 Java 是单继承语言一个类只能有一个父类。既然父类位置被Proxy占了代理类就只能通过实现接口来获得目标类的方法签名。如果目标类没有接口代理类就无法知道要覆写哪些方法也就无法生成。答题时可以补一句这也是为什么 Spring 对无接口的类要切换到 CGLIB因为 CGLIB 走的是继承路线不受这个限制。7.2 JDK 代理和 CGLIB 代理怎么选从约束条件看有接口且不需要代理实现类特有方法用 JDK无接口或需要按实现类类型注入用 CGLIB。从性能看代理类创建阶段 JDK 更快方法调用阶段 CGLIB 略优但 JDK 8 之后差距缩小。从兼容性看CGLIB 对 final 类和方法无能为力JDK 对无接口类无能为力。实际项目里Spring Boot 2.x 默认 CGLIB你基本不用手动选。但如果遇到类型转换问题知道往哪个方向调就能快速定位。7.3 动态代理和反射是什么关系动态代理是反射的一个应用场景但两者不是一回事。反射是“在运行时获取类信息并操作类成员”的能力动态代理是“在运行时生成代理类并拦截方法调用”的机制。JDK 动态代理的实现依赖反射Method.invoke但 CGLIB 主要靠字节码生成反射用得少。面试时把这两个概念区分清楚能体现你对底层机制的理解深度。8. 一些延伸方向动态代理往下挖可以延伸到字节码操作ASM、Javassist、ByteBuddy这些库能让你在更底层操控类的生成CGLIB 本身就是基于 ASM 的。往上走可以研究 Spring AOP 的完整链路从Aspect注解解析到Advisor匹配再到代理对象的创建和调用链的执行。如果你在做 RPC 框架或者中间件动态代理几乎是绕不开的基础设施客户端 stub 的生成、服务端的方法分发都建立在它之上。我个人的习惯是遇到一个框架里“莫名其妙就生效了”的功能就去翻它有没有用动态代理。十有八九答案就在某个InvocationHandler或者MethodInterceptor里。把这个机制吃透你看框架源码的视角会从“它在干嘛”变成“它为什么这么设计”这个转变本身就是进阶的标志。