1. 从“中间商”到“防火墙”代理模式的核心价值如果你写过Java尤其是做过一些需要控制对象访问、增强功能或者延迟加载的项目那你大概率已经和代理模式打过交道了只是可能没意识到它有个这么正式的名字。它不像单例模式那样“名声在外”也不像工厂模式那样“无处不在”但代理模式绝对是Java世界里最实用、最“润物细无声”的设计模式之一。简单来说代理模式就是给某个对象提供一个替身由这个替身来控制对原对象的访问。这个替身就是“代理”。听起来是不是有点像现实生活中的中介、经纪人或者秘书没错就是这个意思。你客户端想找房东真实对象租房子但房东很忙或者不想直接面对租客于是他委托了一个房产中介代理对象。你所有的看房、谈价、签合同的需求都先告诉中介由中介去和房东沟通最后再把结果反馈给你。在这个过程中中介可能还会做一些额外的事情比如审核你的资质、记录看房日志、甚至在你和房东之间做一层缓冲防止你们直接冲突。在Java里代理模式的价值就体现在这些“额外的事情”上。它主要解决几个核心问题访问控制比如权限校验、功能增强比如在方法调用前后加日志、监控、延迟加载比如大对象的初始化放到真正需要时以及简化接口比如为一个复杂系统提供一个简单的门面。当你看到代码里出现InvocationHandler、动态代理这些词或者用到Spring的Transactional、Cacheable注解时背后站着的就是代理模式。对于Java开发者无论是应对面试中“说说你对代理模式的理解”这类八股文还是解决实际开发中“如何无侵入地给方法加监控”这种工程问题吃透代理模式都至关重要。接下来我会抛开教科书式的定义直接从静态代理和动态代理这两种最主流的实现方式入手结合大量代码示例和踩坑经验带你彻底搞懂它。2. 静态代理手把手打造你的专属“中介”静态代理顾名思义就是在编译期就确定好的代理关系。我们需要手动创建一个代理类让它实现和目标对象相同的接口然后在内部持有一个目标对象的引用。所有对目标对象的调用都经过这个代理类“转一手”。2.1 一个经典的业务场景给服务加日志假设我们有一个用户服务接口UserService和它的实现类UserServiceImpl现在有个新需求要在每个业务方法执行前后打印日志记录参数、耗时和结果。最“耿直”的做法是直接修改UserServiceImpl的每一个方法在开头和结尾加上log.info(...)。但这违反了开闭原则对扩展开放对修改关闭而且如果以后不要日志了或者要换成别的增强比如性能监控又得把所有方法再改一遍维护起来是场灾难。这时静态代理就派上用场了。我们创建一个UserServiceProxy类。// 1. 定义业务接口 public interface UserService { void addUser(String username); String getUserById(Long id); } // 2. 真实业务实现类 public class UserServiceImpl implements UserService { Override public void addUser(String username) { System.out.println(真实业务添加用户 username); // 模拟耗时操作 try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } Override public String getUserById(Long id) { System.out.println(真实业务查询用户ID id); return User_ id; } } // 3. 静态代理类 public class UserServiceProxy implements UserService { // 持有真实对象的引用 private UserService target; public UserServiceProxy(UserService target) { this.target target; } Override public void addUser(String username) { long start System.currentTimeMillis(); System.out.println([静态代理-日志] 开始执行 addUser, 参数: username); // 调用真实对象的方法 target.addUser(username); long end System.currentTimeMillis(); System.out.println([静态代理-日志] 结束执行 addUser, 耗时: (end - start) ms); } Override public String getUserById(Long id) { long start System.currentTimeMillis(); System.out.println([静态代理-日志] 开始执行 getUserById, 参数: id); String result target.getUserById(id); long end System.currentTimeMillis(); System.out.println([静态代理-日志] 结束执行 getUserById, 结果: result , 耗时: (end - start) ms); return result; } } // 4. 客户端使用 public class Client { public static void main(String[] args) { // 创建真实对象 UserService realService new UserServiceImpl(); // 创建代理对象将真实对象传入 UserService proxy new UserServiceProxy(realService); // 客户端调用代理对象感觉和调用真实对象一样 proxy.addUser(张三); System.out.println(---); proxy.getUserById(1L); } }运行上面的客户端代码你会看到输出中包含了代理类添加的日志信息而真实业务类的代码丝毫未动。这就是静态代理的核心通过组合和实现相同接口在调用真实方法前后插入自定义逻辑。2.2 静态代理的优缺点与适用场景优点非常明显职责清晰符合开闭原则业务类 (UserServiceImpl) 只关心核心逻辑日志、监控、事务等横切关注点被剥离到代理类中。需要修改增强逻辑时只需改动代理类。客户端无感知对于使用方 (Client) 来说它拿到的虽然是个代理对象但接口和真实对象一模一样调用方式完全不变。编译期检查由于代理类和目标类都实现了同一接口任何不匹配的方法签名在编译时就会报错安全性高。但它的缺点也同样突出类爆炸一个真实类就需要对应一个代理类。如果系统有几十个服务类都需要加日志你就得手动写几十个几乎雷同的代理类代码冗余严重。接口耦合代理类必须实现和目标类一样的接口。如果目标类没有接口虽然不推荐但现实存在或者接口方法很多代理类的编写和维护会很繁琐。灵活性差增强逻辑如日志格式一旦写在代理类里想要动态改变就比较困难。所以静态代理适合什么场景我的经验是它更适合增强逻辑简单、且目标类数量非常有限的情况。比如你系统里就那么两三个核心服务需要做严格的权限校验写两三个静态代理类完全可以接受。或者在早期架构设计时用于快速验证某个横切逻辑如缓存的可行性静态代理是个不错的原型工具。3. 动态代理Java反射机制下的“万能中介”静态代理的痛点在于“静态”——代码写死了。动态代理则是在程序运行时动态地在内存中创建代理类及其对象。在Java中实现动态代理主要依靠java.lang.reflect.Proxy类和java.lang.reflect.InvocationHandler接口。这是Java面试八股文里的常客也是理解Spring AOP等框架的基石。3.1 核心机制Proxy 与 InvocationHandler 的协奏曲Proxy类是生成代理对象的工厂它提供了一个静态方法newProxyInstance。InvocationHandler是一个调用处理器接口你所有的增强逻辑都写在这里面的invoke方法里。当客户端调用代理对象的任何方法时这个调用都会被“路由”到InvocationHandler.invoke方法中。我们来用动态代理重构上面的日志案例import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; // 1. 调用处理器实现类增强逻辑在这里 public class LogInvocationHandler implements InvocationHandler { // 持有真实目标对象 private Object target; public LogInvocationHandler(Object target) { this.target target; } /** * param proxy 动态生成的代理对象本身通常很少直接用 * param method 客户端调用的方法反射对象 * param args 调用方法时传入的参数 * return 方法的返回值 */ Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { long start System.currentTimeMillis(); String methodName method.getName(); System.out.println([动态代理-日志] 开始执行 methodName , 参数: Arrays.toString(args)); // 关键利用反射调用真实对象的方法 Object result method.invoke(target, args); long end System.currentTimeMillis(); System.out.println([动态代理-日志] 结束执行 methodName , 结果: result , 耗时: (end - start) ms); return result; } } // 2. 客户端使用动态代理 public class DynamicProxyClient { public static void main(String[] args) { // 1. 创建真实对象 UserService realService new UserServiceImpl(); // 2. 创建调用处理器传入真实对象 InvocationHandler handler new LogInvocationHandler(realService); // 3. 使用Proxy类动态创建代理对象 // 参数1类加载器通常用目标类的类加载器 // 参数2代理类需要实现的接口数组 // 参数3调用处理器实例 UserService proxy (UserService) Proxy.newProxyInstance( realService.getClass().getClassLoader(), // 类加载器 realService.getClass().getInterfaces(), // 接口数组 handler // 处理器 ); // 4. 像使用真实对象一样使用代理对象 proxy.addUser(李四); System.out.println(---); String user proxy.getUserById(2L); System.out.println(客户端收到结果: user); } }运行这段代码效果和静态代理完全一样。但背后的机制天差地别我们并没有编写UserServiceProxy这个类它是在运行时由JVM动态生成的。你可以通过System.getProperties().put(sun.misc.ProxyGenerator.saveGeneratedFiles, true”);这行代码Java 8及之前将动态生成的代理类字节码保存到磁盘会发现它大概长这样简化版public final class $Proxy0 extends Proxy implements UserService { private static Method m1, m2, m3, m4; // 比如m3对应addUser, m4对应getUserById public $Proxy0(InvocationHandler h) { super(h); } Override public final void addUser(String var1) { try { // 将调用委托给InvocationHandler.invoke super.h.invoke(this, m3, new Object[]{var1}); } catch (Throwable e) {...} } Override public final String getUserById(Long var1) { try { return (String) super.h.invoke(this, m4, new Object[]{var1}); } catch (Throwable e) {...} } }可以看到动态生成的代理类继承了Proxy类并实现了UserService接口。它内部的方法实现就是简单地调用我们传入的InvocationHandler的invoke方法。这就是动态代理的精髓将增强逻辑Handler和代理对象的生成Proxy解耦。3.2 动态代理的威力与关键细节动态代理的优势是碾压性的一劳永逸一个InvocationHandler可以代理无数个不同的接口和类。只要它们需要相同的增强逻辑比如日志你就只需要写一个处理器。极度灵活增强逻辑 (invoke方法) 可以基于方法名、参数、注解等进行动态判断实现非常精细的控制。例如你可以只给带有Monitor注解的方法加性能监控。减少冗余彻底解决了静态代理的“类爆炸”问题。但在使用中有几个关键细节和坑需要特别注意细节一只能代理接口Proxy.newProxyInstance的第二个参数是接口数组。这意味着Java原生动态代理只能基于接口实现不能代理普通类。这是由它的实现机制决定的生成的代理类已经继承了ProxyJava是单继承。如果你需要代理类就需要用到CGLIB、ByteBuddy这类第三方字节码操作库这也是Spring默认在目标类没有接口时使用的方案。细节二invoke方法内的proxy参数invoke方法的第一个参数是代理对象本身。在invoke方法内部如果你通过这个proxy参数再去调用代理方法会导致无限递归调用最终栈溢出StackOverflowError。这是一个经典大坑。Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 错误示例这会导致无限递归 // method.invoke(proxy, args); // 正确做法调用真实目标对象 target return method.invoke(target, args); }细节三对equals,hashCode,toString等方法的影响因为代理类实现了接口而所有Java对象都继承自Object所以像equals,hashCode,toString这些Object类的方法也会被代理。如果你的InvocationHandler里对这些方法做了通用处理比如日志可能会产生意想不到的效果。有时你需要过滤掉这些方法Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 如果是Object类的基础方法直接调用不做增强 if (method.getDeclaringClass() Object.class) { return method.invoke(target, args); } // ... 其他增强逻辑 }细节四性能开销动态代理利用反射 (method.invoke) 调用方法这比直接的方法调用会有一定的性能损耗。但在绝大多数业务场景下这点开销与它带来的维护性和灵活性收益相比是微不足道的。只有在极端性能敏感的核心路径上才需要考虑。4. 实战中的经典应用场景与避坑指南理解了基本原理我们来看看代理模式在真实项目里是怎么大显身手的。这远比死记硬背定义更有价值。4.1 场景一Spring AOP 与声明式事务Spring框架的面向切面编程AOP和声明式事务管理 (Transactional)是动态代理最教科书式的应用。当你在一个Service方法上标注Transactional时Spring容器在启动时就会为这个Service Bean创建一个代理对象可能是JDK动态代理也可能是CGLIB代理。这个代理对象的InvocationHandler里包含了复杂的事务管理逻辑在invoke方法开始时它会根据Transactional的配置决定是否开启新事务、挂起现有事务、设置隔离级别和传播行为等然后调用真实业务方法。业务方法执行完毕后代理逻辑再根据执行结果是否抛出异常决定是提交事务还是回滚。避坑点自调用失效问题这是Spring AOP代理包括事务的一个著名陷阱。在同一个类中一个非事务方法A调用另一个事务方法BB方法的事务注解会失效。Service public class OrderService { public void placeOrder(Order order) { // 非事务方法 // ... 一些校验逻辑 this.updateInventory(order); // 自调用事务失效 } Transactional public void updateInventory(Order order) { // 更新库存希望有事务 } }原因placeOrder方法中调用的this.updateInventory()这个this指的是真实的OrderService对象本身而不是Spring注入的那个代理对象。代理对象的事务增强逻辑根本没有机会执行。解决方案将两个方法拆分到不同的类中。通过AopContext获取当前代理对象需要开启exposeProxy:((OrderService) AopContext.currentProxy()).updateInventory(order)。不推荐使用AspectJ的编译时或加载时织入LTW它可以直接修改字节码不依赖代理。4.2 场景二RPC框架的客户端存根Stub在Dubbo、gRPC等RPC框架中客户端调用远程服务就像调用本地接口一样简单。这背后的魔法就是动态代理。框架在启动时会为你的服务接口如UserService动态生成一个代理对象。当你调用proxy.getUserById(1L)时代理逻辑InvocationHandler并不会去执行本地代码而是会将方法名、参数类型、参数值等信息序列化成网络传输格式如JSON、Protobuf。通过网络客户端如Netty将请求发送到远程服务器。接收服务器返回的响应并反序列化成Java对象。将这个对象作为结果返回给调用者。整个过程对业务开发者完全透明。这就是代理模式“隐藏复杂性”和“控制访问”的完美体现。4.3 场景三MyBatis的Mapper接口实现MyBatis的Mapper接口我们只定义了方法并没有写实现类但SqlSession.getMapper()却能返回一个可以执行SQL的对象。这同样是动态代理的功劳。MyBatis使用MapperProxy作为InvocationHandler。当调用Mapper接口的方法时invoke方法会根据接口全限定名和方法名找到映射文件中对应的SQL语句select id”…”。解析方法参数将其设置到SQL的预编译参数中。执行SQL并通过ResultHandler或类型转换器将结果集转换成方法声明的返回类型如ListUser。返回结果。避坑点方法重载MyBatis的Mapper接口不支持方法重载。因为它是通过“接口全限定名方法名”作为唯一键去查找SQL语句的。如果有两个同名方法即使参数不同MyBatis也无法区分该执行哪条SQL。// 错误示例 public interface UserMapper { User selectById(Long id); ListUser selectById(Long id, String status); // 编译通过但运行时会出错 }4.4 场景四简易缓存代理我们可以轻松地用动态代理实现一个方法级的缓存这是展示其灵活性的好例子。public class CacheInvocationHandler implements InvocationHandler { private Object target; private MapString, Object cache new ConcurrentHashMap(); public CacheInvocationHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 构造缓存键这里简单用 类名方法名参数哈希 String key method.getDeclaringClass().getName() # method.getName() Arrays.deepHashCode(args); // 2. 先查缓存 if (cache.containsKey(key)) { System.out.println([缓存代理] 命中缓存key: key); return cache.get(key); } // 3. 缓存未命中调用真实方法 System.out.println([缓存代理] 未命中缓存执行真实方法key: key); Object result method.invoke(target, args); // 4. 将结果放入缓存这里可以加过期时间、大小限制等复杂逻辑 cache.put(key, result); return result; } }这个简单的处理器可以为任何接口的方法调用加上一层缓存。在实际项目中你可以结合注解如Cacheable来实现更精细的缓存控制哪些方法缓存、缓存多久、用什么Key都可以通过注解配置然后在InvocationHandler里解析注解来执行相应逻辑。5. 深入原理JDK动态代理的生成与调用链路为了更彻底地理解动态代理避免停留在“会用但不知其所以然”的层面我们有必要深入看看Proxy.newProxyInstance背后到底发生了什么。这对于排查一些诡异问题比如上面提到的自调用、方法签名不对应非常有帮助。5.1 代理类的生成过程当你调用Proxy.newProxyInstance(ClassLoader loader, Class?[] interfaces, InvocationHandler h)时JDK内部大致做了以下几件事验证与安全检查检查传入的ClassLoader和接口数组是否有效。例如接口不能重复、必须是接口类型而不能是类、该类加载器必须能“看见”这些接口等。生成代理类字节码这是核心步骤。JDK会动态生成一个代理类的字节码。这个类类名通常是$ProxyN的形式N是递增的数字。继承自java.lang.reflect.Proxy类。实现你传入的所有接口。为每个接口中的每个方法包括从父接口继承来的生成对应的实现方法。这些方法的实现体逻辑高度一致调用父类Proxy中持有的InvocationHandler对象的invoke方法。还会生成equals,hashCode,toString等方法这些方法的实现同样委托给InvocationHandler。定义并加载类将生成的字节码通过传入的ClassLoader定义到JVM中得到Class?对象。实例化代理对象通过反射调用这个代理类的构造方法该构造方法需要一个InvocationHandler参数将我们传入的InvocationHandler实例传进去创建出最终的代理对象。你可以把Proxy类想象成一个“代理类的蓝图工厂”它知道如何按照固定模板继承Proxy、实现接口、方法委托给Handler来“打印”出具体的代理类。5.2 方法调用的完整链路理解了生成过程调用链路就清晰了客户端代码调用 proxy.method(args) ↓ 进入动态生成的 $Proxy0.method(args) 方法 ↓ 该方法内部调用 super.h.invoke(this, methodObj, args) ↓ 进入我们编写的 LogInvocationHandler.invoke(proxy, methodObj, args) ↓ 我们在 invoke 中执行增强逻辑如日志并通过 method.invoke(target, args) 调用真实对象方法 ↓ 真实对象方法执行并返回结果 ↓ 结果返回到 invoke 方法我们可以再次增强如记录结果 ↓ 结果最终返回到 $Proxy0.method再返回给客户端这个链路解释了为什么“自调用”会失效。因为自调用时this指向的是真实对象调用链路直接从“真实对象”开始跳过了前面所有的代理环节。5.3 性能考量与替代方案由于动态代理涉及运行时字节码生成和反射调用其性能确实比直接调用稍差。但在99%的应用中这点开销可以忽略不计。如果真遇到了极端性能瓶颈并且确认是代理导致的可以考虑以下方案缓存代理类Proxy类内部其实有缓存机制对同一组接口和类加载器它会返回缓存的代理类Class对象避免重复生成字节码。我们一般无需自己再缓存。使用CGLIB/ByteBuddy当目标类没有接口时Spring AOP会默认使用CGLIB。CGLIB通过继承目标类并重写方法的方式创建代理它生成的是目标类的子类。因为是通过继承关系方法调用是直接的使用super调用父类方法理论上比基于接口和反射的JDK动态代理稍快。但创建代理对象的过程可能更耗时。AspectJ编译时织入CTW这是最彻底的方案。它在编译阶段或类加载阶段就直接将增强代码“编织”进目标类的字节码中运行时没有任何代理开销就是普通的Java方法调用。但它的工具链更复杂对构建过程有侵入。我的建议是除非有确凿的性能分析证据否则优先使用JDK动态代理或Spring AOP它帮你做了最佳选择。过早优化是万恶之源。6. 模式对比与扩展静态代理、动态代理与其他模式设计模式之间常有相似之处清晰地区分它们能帮助我们更好地理解和运用。6.1 静态代理 vs 动态代理特性静态代理JDK动态代理实现方式手动编写代理类实现相同接口运行时通过Proxy和InvocationHandler动态生成编码量大每个目标类需对应一个代理类小一个处理器可代理多个类灵活性低增强逻辑写死在代理类中高增强逻辑可在处理器中动态判断目标要求目标类必须实现接口或继承指定父类目标类必须实现至少一个接口编译期检查强代理类需实现所有接口方法强通过接口约定性能与直接调用几乎无差略有反射开销通常可忽略选择原则需要代理的类少且逻辑固定用静态代理简单直观。需要代理的类多或逻辑需动态变化用动态代理。6.2 代理模式 vs 装饰器模式这两个模式在结构上非常相似都是通过组合持有目标对象并实现相同接口。它们的核心区别在于目的代理模式目的是控制访问。代理对象决定是否、何时、如何将请求转发给真实对象。焦点在于“访问”本身比如权限校验、延迟初始化、远程访问。代理对象和真实对象的关系通常是固定的一个代理对应一个真实对象。装饰器模式目的是增强功能。装饰器对象为真实对象添加新的职责或行为焦点在于“功能”叠加。装饰器对象和真实对象的关系是灵活的可以多层嵌套一个对象可以被多个装饰器包裹像洋葱一样层层叠加功能如BufferedInputStream(FileInputStream)。简单记代理是“经纪人”控制你见不见明星装饰器是“服装师”给明星穿上一件又一件衣服。6.3 代理模式 vs 适配器模式适配器模式关注的是接口转换解决接口不兼容的问题比如将欧洲插头转换成中国插座。它也会持有一个被适配对象但目的是改变其接口形式以便客户端使用。 代理模式不改变接口它提供的是完全相同的接口只是在调用过程中加入了控制或增强。7. 总结与最佳实践心得代理模式特别是动态代理是Java高级编程和框架设计的核心支柱之一。它优雅地解决了横切关注点日志、事务、安全等与核心业务逻辑分离的难题。回顾整个探索过程我想分享几点在实战中积累的心得明确代理的意图在决定使用代理前先问自己我主要想做什么是控制访问如权限、增强功能如缓存、简化接口如门面、还是延迟加载如虚拟代理不同的意图可能会影响代理的实现细节。优先考虑基于接口的设计无论是为了使用JDK动态代理还是为了更好的代码抽象和可测试性尽量让核心业务类实现接口。这会给应用代理模式带来极大的便利。小心处理InvocationHandler中的异常在invoke方法中method.invoke(target, args)可能会抛出各种受检和非受检异常。你的处理器需要决定是直接抛出、包装后抛出、还是吞掉异常进行降级处理。特别是在实现事务代理时对异常的处理直接决定了事务是提交还是回滚。关注代理对象的身份在日志或调试时打印proxy.getClass().getName()会让你看到类似com.sun.proxy.$Proxy0这样的类名提醒你正在操作一个代理对象。这在排查“为什么我的注解没生效”这类问题时非常有用。在Spring环境中信任容器对于Spring管理的Bean如果你需要AOP功能事务、缓存、安全等就放心地使用Transactional、Cacheable等注解让Spring去处理代理的创建。99%的情况你都不需要手动创建Proxy对象。只有在需要深度定制或集成非Spring管理的组件时才考虑手动使用动态代理。最后代理模式是一种强大的工具但也不要过度设计。如果某个增强逻辑只在一个地方用到也许直接写在该方法里更简单清晰。判断的标准是变化的可能性如果这个逻辑未来很可能变化或者需要应用到多个地方那么将其抽离出来用代理或AOP实现就是值得的。 Java代理模式深度解析：从静态代理到动态代理的实战应用
1. 从“中间商”到“防火墙”代理模式的核心价值如果你写过Java尤其是做过一些需要控制对象访问、增强功能或者延迟加载的项目那你大概率已经和代理模式打过交道了只是可能没意识到它有个这么正式的名字。它不像单例模式那样“名声在外”也不像工厂模式那样“无处不在”但代理模式绝对是Java世界里最实用、最“润物细无声”的设计模式之一。简单来说代理模式就是给某个对象提供一个替身由这个替身来控制对原对象的访问。这个替身就是“代理”。听起来是不是有点像现实生活中的中介、经纪人或者秘书没错就是这个意思。你客户端想找房东真实对象租房子但房东很忙或者不想直接面对租客于是他委托了一个房产中介代理对象。你所有的看房、谈价、签合同的需求都先告诉中介由中介去和房东沟通最后再把结果反馈给你。在这个过程中中介可能还会做一些额外的事情比如审核你的资质、记录看房日志、甚至在你和房东之间做一层缓冲防止你们直接冲突。在Java里代理模式的价值就体现在这些“额外的事情”上。它主要解决几个核心问题访问控制比如权限校验、功能增强比如在方法调用前后加日志、监控、延迟加载比如大对象的初始化放到真正需要时以及简化接口比如为一个复杂系统提供一个简单的门面。当你看到代码里出现InvocationHandler、动态代理这些词或者用到Spring的Transactional、Cacheable注解时背后站着的就是代理模式。对于Java开发者无论是应对面试中“说说你对代理模式的理解”这类八股文还是解决实际开发中“如何无侵入地给方法加监控”这种工程问题吃透代理模式都至关重要。接下来我会抛开教科书式的定义直接从静态代理和动态代理这两种最主流的实现方式入手结合大量代码示例和踩坑经验带你彻底搞懂它。2. 静态代理手把手打造你的专属“中介”静态代理顾名思义就是在编译期就确定好的代理关系。我们需要手动创建一个代理类让它实现和目标对象相同的接口然后在内部持有一个目标对象的引用。所有对目标对象的调用都经过这个代理类“转一手”。2.1 一个经典的业务场景给服务加日志假设我们有一个用户服务接口UserService和它的实现类UserServiceImpl现在有个新需求要在每个业务方法执行前后打印日志记录参数、耗时和结果。最“耿直”的做法是直接修改UserServiceImpl的每一个方法在开头和结尾加上log.info(...)。但这违反了开闭原则对扩展开放对修改关闭而且如果以后不要日志了或者要换成别的增强比如性能监控又得把所有方法再改一遍维护起来是场灾难。这时静态代理就派上用场了。我们创建一个UserServiceProxy类。// 1. 定义业务接口 public interface UserService { void addUser(String username); String getUserById(Long id); } // 2. 真实业务实现类 public class UserServiceImpl implements UserService { Override public void addUser(String username) { System.out.println(真实业务添加用户 username); // 模拟耗时操作 try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } Override public String getUserById(Long id) { System.out.println(真实业务查询用户ID id); return User_ id; } } // 3. 静态代理类 public class UserServiceProxy implements UserService { // 持有真实对象的引用 private UserService target; public UserServiceProxy(UserService target) { this.target target; } Override public void addUser(String username) { long start System.currentTimeMillis(); System.out.println([静态代理-日志] 开始执行 addUser, 参数: username); // 调用真实对象的方法 target.addUser(username); long end System.currentTimeMillis(); System.out.println([静态代理-日志] 结束执行 addUser, 耗时: (end - start) ms); } Override public String getUserById(Long id) { long start System.currentTimeMillis(); System.out.println([静态代理-日志] 开始执行 getUserById, 参数: id); String result target.getUserById(id); long end System.currentTimeMillis(); System.out.println([静态代理-日志] 结束执行 getUserById, 结果: result , 耗时: (end - start) ms); return result; } } // 4. 客户端使用 public class Client { public static void main(String[] args) { // 创建真实对象 UserService realService new UserServiceImpl(); // 创建代理对象将真实对象传入 UserService proxy new UserServiceProxy(realService); // 客户端调用代理对象感觉和调用真实对象一样 proxy.addUser(张三); System.out.println(---); proxy.getUserById(1L); } }运行上面的客户端代码你会看到输出中包含了代理类添加的日志信息而真实业务类的代码丝毫未动。这就是静态代理的核心通过组合和实现相同接口在调用真实方法前后插入自定义逻辑。2.2 静态代理的优缺点与适用场景优点非常明显职责清晰符合开闭原则业务类 (UserServiceImpl) 只关心核心逻辑日志、监控、事务等横切关注点被剥离到代理类中。需要修改增强逻辑时只需改动代理类。客户端无感知对于使用方 (Client) 来说它拿到的虽然是个代理对象但接口和真实对象一模一样调用方式完全不变。编译期检查由于代理类和目标类都实现了同一接口任何不匹配的方法签名在编译时就会报错安全性高。但它的缺点也同样突出类爆炸一个真实类就需要对应一个代理类。如果系统有几十个服务类都需要加日志你就得手动写几十个几乎雷同的代理类代码冗余严重。接口耦合代理类必须实现和目标类一样的接口。如果目标类没有接口虽然不推荐但现实存在或者接口方法很多代理类的编写和维护会很繁琐。灵活性差增强逻辑如日志格式一旦写在代理类里想要动态改变就比较困难。所以静态代理适合什么场景我的经验是它更适合增强逻辑简单、且目标类数量非常有限的情况。比如你系统里就那么两三个核心服务需要做严格的权限校验写两三个静态代理类完全可以接受。或者在早期架构设计时用于快速验证某个横切逻辑如缓存的可行性静态代理是个不错的原型工具。3. 动态代理Java反射机制下的“万能中介”静态代理的痛点在于“静态”——代码写死了。动态代理则是在程序运行时动态地在内存中创建代理类及其对象。在Java中实现动态代理主要依靠java.lang.reflect.Proxy类和java.lang.reflect.InvocationHandler接口。这是Java面试八股文里的常客也是理解Spring AOP等框架的基石。3.1 核心机制Proxy 与 InvocationHandler 的协奏曲Proxy类是生成代理对象的工厂它提供了一个静态方法newProxyInstance。InvocationHandler是一个调用处理器接口你所有的增强逻辑都写在这里面的invoke方法里。当客户端调用代理对象的任何方法时这个调用都会被“路由”到InvocationHandler.invoke方法中。我们来用动态代理重构上面的日志案例import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; // 1. 调用处理器实现类增强逻辑在这里 public class LogInvocationHandler implements InvocationHandler { // 持有真实目标对象 private Object target; public LogInvocationHandler(Object target) { this.target target; } /** * param proxy 动态生成的代理对象本身通常很少直接用 * param method 客户端调用的方法反射对象 * param args 调用方法时传入的参数 * return 方法的返回值 */ Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { long start System.currentTimeMillis(); String methodName method.getName(); System.out.println([动态代理-日志] 开始执行 methodName , 参数: Arrays.toString(args)); // 关键利用反射调用真实对象的方法 Object result method.invoke(target, args); long end System.currentTimeMillis(); System.out.println([动态代理-日志] 结束执行 methodName , 结果: result , 耗时: (end - start) ms); return result; } } // 2. 客户端使用动态代理 public class DynamicProxyClient { public static void main(String[] args) { // 1. 创建真实对象 UserService realService new UserServiceImpl(); // 2. 创建调用处理器传入真实对象 InvocationHandler handler new LogInvocationHandler(realService); // 3. 使用Proxy类动态创建代理对象 // 参数1类加载器通常用目标类的类加载器 // 参数2代理类需要实现的接口数组 // 参数3调用处理器实例 UserService proxy (UserService) Proxy.newProxyInstance( realService.getClass().getClassLoader(), // 类加载器 realService.getClass().getInterfaces(), // 接口数组 handler // 处理器 ); // 4. 像使用真实对象一样使用代理对象 proxy.addUser(李四); System.out.println(---); String user proxy.getUserById(2L); System.out.println(客户端收到结果: user); } }运行这段代码效果和静态代理完全一样。但背后的机制天差地别我们并没有编写UserServiceProxy这个类它是在运行时由JVM动态生成的。你可以通过System.getProperties().put(sun.misc.ProxyGenerator.saveGeneratedFiles, true”);这行代码Java 8及之前将动态生成的代理类字节码保存到磁盘会发现它大概长这样简化版public final class $Proxy0 extends Proxy implements UserService { private static Method m1, m2, m3, m4; // 比如m3对应addUser, m4对应getUserById public $Proxy0(InvocationHandler h) { super(h); } Override public final void addUser(String var1) { try { // 将调用委托给InvocationHandler.invoke super.h.invoke(this, m3, new Object[]{var1}); } catch (Throwable e) {...} } Override public final String getUserById(Long var1) { try { return (String) super.h.invoke(this, m4, new Object[]{var1}); } catch (Throwable e) {...} } }可以看到动态生成的代理类继承了Proxy类并实现了UserService接口。它内部的方法实现就是简单地调用我们传入的InvocationHandler的invoke方法。这就是动态代理的精髓将增强逻辑Handler和代理对象的生成Proxy解耦。3.2 动态代理的威力与关键细节动态代理的优势是碾压性的一劳永逸一个InvocationHandler可以代理无数个不同的接口和类。只要它们需要相同的增强逻辑比如日志你就只需要写一个处理器。极度灵活增强逻辑 (invoke方法) 可以基于方法名、参数、注解等进行动态判断实现非常精细的控制。例如你可以只给带有Monitor注解的方法加性能监控。减少冗余彻底解决了静态代理的“类爆炸”问题。但在使用中有几个关键细节和坑需要特别注意细节一只能代理接口Proxy.newProxyInstance的第二个参数是接口数组。这意味着Java原生动态代理只能基于接口实现不能代理普通类。这是由它的实现机制决定的生成的代理类已经继承了ProxyJava是单继承。如果你需要代理类就需要用到CGLIB、ByteBuddy这类第三方字节码操作库这也是Spring默认在目标类没有接口时使用的方案。细节二invoke方法内的proxy参数invoke方法的第一个参数是代理对象本身。在invoke方法内部如果你通过这个proxy参数再去调用代理方法会导致无限递归调用最终栈溢出StackOverflowError。这是一个经典大坑。Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 错误示例这会导致无限递归 // method.invoke(proxy, args); // 正确做法调用真实目标对象 target return method.invoke(target, args); }细节三对equals,hashCode,toString等方法的影响因为代理类实现了接口而所有Java对象都继承自Object所以像equals,hashCode,toString这些Object类的方法也会被代理。如果你的InvocationHandler里对这些方法做了通用处理比如日志可能会产生意想不到的效果。有时你需要过滤掉这些方法Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 如果是Object类的基础方法直接调用不做增强 if (method.getDeclaringClass() Object.class) { return method.invoke(target, args); } // ... 其他增强逻辑 }细节四性能开销动态代理利用反射 (method.invoke) 调用方法这比直接的方法调用会有一定的性能损耗。但在绝大多数业务场景下这点开销与它带来的维护性和灵活性收益相比是微不足道的。只有在极端性能敏感的核心路径上才需要考虑。4. 实战中的经典应用场景与避坑指南理解了基本原理我们来看看代理模式在真实项目里是怎么大显身手的。这远比死记硬背定义更有价值。4.1 场景一Spring AOP 与声明式事务Spring框架的面向切面编程AOP和声明式事务管理 (Transactional)是动态代理最教科书式的应用。当你在一个Service方法上标注Transactional时Spring容器在启动时就会为这个Service Bean创建一个代理对象可能是JDK动态代理也可能是CGLIB代理。这个代理对象的InvocationHandler里包含了复杂的事务管理逻辑在invoke方法开始时它会根据Transactional的配置决定是否开启新事务、挂起现有事务、设置隔离级别和传播行为等然后调用真实业务方法。业务方法执行完毕后代理逻辑再根据执行结果是否抛出异常决定是提交事务还是回滚。避坑点自调用失效问题这是Spring AOP代理包括事务的一个著名陷阱。在同一个类中一个非事务方法A调用另一个事务方法BB方法的事务注解会失效。Service public class OrderService { public void placeOrder(Order order) { // 非事务方法 // ... 一些校验逻辑 this.updateInventory(order); // 自调用事务失效 } Transactional public void updateInventory(Order order) { // 更新库存希望有事务 } }原因placeOrder方法中调用的this.updateInventory()这个this指的是真实的OrderService对象本身而不是Spring注入的那个代理对象。代理对象的事务增强逻辑根本没有机会执行。解决方案将两个方法拆分到不同的类中。通过AopContext获取当前代理对象需要开启exposeProxy:((OrderService) AopContext.currentProxy()).updateInventory(order)。不推荐使用AspectJ的编译时或加载时织入LTW它可以直接修改字节码不依赖代理。4.2 场景二RPC框架的客户端存根Stub在Dubbo、gRPC等RPC框架中客户端调用远程服务就像调用本地接口一样简单。这背后的魔法就是动态代理。框架在启动时会为你的服务接口如UserService动态生成一个代理对象。当你调用proxy.getUserById(1L)时代理逻辑InvocationHandler并不会去执行本地代码而是会将方法名、参数类型、参数值等信息序列化成网络传输格式如JSON、Protobuf。通过网络客户端如Netty将请求发送到远程服务器。接收服务器返回的响应并反序列化成Java对象。将这个对象作为结果返回给调用者。整个过程对业务开发者完全透明。这就是代理模式“隐藏复杂性”和“控制访问”的完美体现。4.3 场景三MyBatis的Mapper接口实现MyBatis的Mapper接口我们只定义了方法并没有写实现类但SqlSession.getMapper()却能返回一个可以执行SQL的对象。这同样是动态代理的功劳。MyBatis使用MapperProxy作为InvocationHandler。当调用Mapper接口的方法时invoke方法会根据接口全限定名和方法名找到映射文件中对应的SQL语句select id”…”。解析方法参数将其设置到SQL的预编译参数中。执行SQL并通过ResultHandler或类型转换器将结果集转换成方法声明的返回类型如ListUser。返回结果。避坑点方法重载MyBatis的Mapper接口不支持方法重载。因为它是通过“接口全限定名方法名”作为唯一键去查找SQL语句的。如果有两个同名方法即使参数不同MyBatis也无法区分该执行哪条SQL。// 错误示例 public interface UserMapper { User selectById(Long id); ListUser selectById(Long id, String status); // 编译通过但运行时会出错 }4.4 场景四简易缓存代理我们可以轻松地用动态代理实现一个方法级的缓存这是展示其灵活性的好例子。public class CacheInvocationHandler implements InvocationHandler { private Object target; private MapString, Object cache new ConcurrentHashMap(); public CacheInvocationHandler(Object target) { this.target target; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 构造缓存键这里简单用 类名方法名参数哈希 String key method.getDeclaringClass().getName() # method.getName() Arrays.deepHashCode(args); // 2. 先查缓存 if (cache.containsKey(key)) { System.out.println([缓存代理] 命中缓存key: key); return cache.get(key); } // 3. 缓存未命中调用真实方法 System.out.println([缓存代理] 未命中缓存执行真实方法key: key); Object result method.invoke(target, args); // 4. 将结果放入缓存这里可以加过期时间、大小限制等复杂逻辑 cache.put(key, result); return result; } }这个简单的处理器可以为任何接口的方法调用加上一层缓存。在实际项目中你可以结合注解如Cacheable来实现更精细的缓存控制哪些方法缓存、缓存多久、用什么Key都可以通过注解配置然后在InvocationHandler里解析注解来执行相应逻辑。5. 深入原理JDK动态代理的生成与调用链路为了更彻底地理解动态代理避免停留在“会用但不知其所以然”的层面我们有必要深入看看Proxy.newProxyInstance背后到底发生了什么。这对于排查一些诡异问题比如上面提到的自调用、方法签名不对应非常有帮助。5.1 代理类的生成过程当你调用Proxy.newProxyInstance(ClassLoader loader, Class?[] interfaces, InvocationHandler h)时JDK内部大致做了以下几件事验证与安全检查检查传入的ClassLoader和接口数组是否有效。例如接口不能重复、必须是接口类型而不能是类、该类加载器必须能“看见”这些接口等。生成代理类字节码这是核心步骤。JDK会动态生成一个代理类的字节码。这个类类名通常是$ProxyN的形式N是递增的数字。继承自java.lang.reflect.Proxy类。实现你传入的所有接口。为每个接口中的每个方法包括从父接口继承来的生成对应的实现方法。这些方法的实现体逻辑高度一致调用父类Proxy中持有的InvocationHandler对象的invoke方法。还会生成equals,hashCode,toString等方法这些方法的实现同样委托给InvocationHandler。定义并加载类将生成的字节码通过传入的ClassLoader定义到JVM中得到Class?对象。实例化代理对象通过反射调用这个代理类的构造方法该构造方法需要一个InvocationHandler参数将我们传入的InvocationHandler实例传进去创建出最终的代理对象。你可以把Proxy类想象成一个“代理类的蓝图工厂”它知道如何按照固定模板继承Proxy、实现接口、方法委托给Handler来“打印”出具体的代理类。5.2 方法调用的完整链路理解了生成过程调用链路就清晰了客户端代码调用 proxy.method(args) ↓ 进入动态生成的 $Proxy0.method(args) 方法 ↓ 该方法内部调用 super.h.invoke(this, methodObj, args) ↓ 进入我们编写的 LogInvocationHandler.invoke(proxy, methodObj, args) ↓ 我们在 invoke 中执行增强逻辑如日志并通过 method.invoke(target, args) 调用真实对象方法 ↓ 真实对象方法执行并返回结果 ↓ 结果返回到 invoke 方法我们可以再次增强如记录结果 ↓ 结果最终返回到 $Proxy0.method再返回给客户端这个链路解释了为什么“自调用”会失效。因为自调用时this指向的是真实对象调用链路直接从“真实对象”开始跳过了前面所有的代理环节。5.3 性能考量与替代方案由于动态代理涉及运行时字节码生成和反射调用其性能确实比直接调用稍差。但在99%的应用中这点开销可以忽略不计。如果真遇到了极端性能瓶颈并且确认是代理导致的可以考虑以下方案缓存代理类Proxy类内部其实有缓存机制对同一组接口和类加载器它会返回缓存的代理类Class对象避免重复生成字节码。我们一般无需自己再缓存。使用CGLIB/ByteBuddy当目标类没有接口时Spring AOP会默认使用CGLIB。CGLIB通过继承目标类并重写方法的方式创建代理它生成的是目标类的子类。因为是通过继承关系方法调用是直接的使用super调用父类方法理论上比基于接口和反射的JDK动态代理稍快。但创建代理对象的过程可能更耗时。AspectJ编译时织入CTW这是最彻底的方案。它在编译阶段或类加载阶段就直接将增强代码“编织”进目标类的字节码中运行时没有任何代理开销就是普通的Java方法调用。但它的工具链更复杂对构建过程有侵入。我的建议是除非有确凿的性能分析证据否则优先使用JDK动态代理或Spring AOP它帮你做了最佳选择。过早优化是万恶之源。6. 模式对比与扩展静态代理、动态代理与其他模式设计模式之间常有相似之处清晰地区分它们能帮助我们更好地理解和运用。6.1 静态代理 vs 动态代理特性静态代理JDK动态代理实现方式手动编写代理类实现相同接口运行时通过Proxy和InvocationHandler动态生成编码量大每个目标类需对应一个代理类小一个处理器可代理多个类灵活性低增强逻辑写死在代理类中高增强逻辑可在处理器中动态判断目标要求目标类必须实现接口或继承指定父类目标类必须实现至少一个接口编译期检查强代理类需实现所有接口方法强通过接口约定性能与直接调用几乎无差略有反射开销通常可忽略选择原则需要代理的类少且逻辑固定用静态代理简单直观。需要代理的类多或逻辑需动态变化用动态代理。6.2 代理模式 vs 装饰器模式这两个模式在结构上非常相似都是通过组合持有目标对象并实现相同接口。它们的核心区别在于目的代理模式目的是控制访问。代理对象决定是否、何时、如何将请求转发给真实对象。焦点在于“访问”本身比如权限校验、延迟初始化、远程访问。代理对象和真实对象的关系通常是固定的一个代理对应一个真实对象。装饰器模式目的是增强功能。装饰器对象为真实对象添加新的职责或行为焦点在于“功能”叠加。装饰器对象和真实对象的关系是灵活的可以多层嵌套一个对象可以被多个装饰器包裹像洋葱一样层层叠加功能如BufferedInputStream(FileInputStream)。简单记代理是“经纪人”控制你见不见明星装饰器是“服装师”给明星穿上一件又一件衣服。6.3 代理模式 vs 适配器模式适配器模式关注的是接口转换解决接口不兼容的问题比如将欧洲插头转换成中国插座。它也会持有一个被适配对象但目的是改变其接口形式以便客户端使用。 代理模式不改变接口它提供的是完全相同的接口只是在调用过程中加入了控制或增强。7. 总结与最佳实践心得代理模式特别是动态代理是Java高级编程和框架设计的核心支柱之一。它优雅地解决了横切关注点日志、事务、安全等与核心业务逻辑分离的难题。回顾整个探索过程我想分享几点在实战中积累的心得明确代理的意图在决定使用代理前先问自己我主要想做什么是控制访问如权限、增强功能如缓存、简化接口如门面、还是延迟加载如虚拟代理不同的意图可能会影响代理的实现细节。优先考虑基于接口的设计无论是为了使用JDK动态代理还是为了更好的代码抽象和可测试性尽量让核心业务类实现接口。这会给应用代理模式带来极大的便利。小心处理InvocationHandler中的异常在invoke方法中method.invoke(target, args)可能会抛出各种受检和非受检异常。你的处理器需要决定是直接抛出、包装后抛出、还是吞掉异常进行降级处理。特别是在实现事务代理时对异常的处理直接决定了事务是提交还是回滚。关注代理对象的身份在日志或调试时打印proxy.getClass().getName()会让你看到类似com.sun.proxy.$Proxy0这样的类名提醒你正在操作一个代理对象。这在排查“为什么我的注解没生效”这类问题时非常有用。在Spring环境中信任容器对于Spring管理的Bean如果你需要AOP功能事务、缓存、安全等就放心地使用Transactional、Cacheable等注解让Spring去处理代理的创建。99%的情况你都不需要手动创建Proxy对象。只有在需要深度定制或集成非Spring管理的组件时才考虑手动使用动态代理。最后代理模式是一种强大的工具但也不要过度设计。如果某个增强逻辑只在一个地方用到也许直接写在该方法里更简单清晰。判断的标准是变化的可能性如果这个逻辑未来很可能变化或者需要应用到多个地方那么将其抽离出来用代理或AOP实现就是值得的。