1. 项目概述为什么我们需要代理模式在Java开发中尤其是构建复杂的企业级应用时我们经常会遇到一个经典问题如何在不修改原有对象核心逻辑的前提下为其增加额外的功能比如日志记录、性能监控、事务管理、安全检查等直接修改源代码不仅违反了“开闭原则”还会让代码变得臃肿且难以维护。这时候“代理模式”就闪亮登场了。简单来说代理模式就是找一个“中介”来帮你做事。这个中介代理对象会持有真实对象目标对象的引用并在调用真实对象的方法前后插入一些自己的“小动作”。对于调用者而言它感知不到代理的存在以为自己是在直接和真实对象打交道但实际上所有的请求都经过了代理的“过滤”和“增强”。举个例子明星和经纪人的关系就是典型的代理模式。你想邀请明星演出不能直接联系明星本人目标对象必须先通过他的经纪人代理对象。经纪人会帮你安排行程、洽谈费用前置处理在演出结束后可能还会处理后续的媒体采访后置处理。整个过程你只和经纪人沟通明星只负责核心的“演出”工作。在Java世界里代理主要分为两大类静态代理和动态代理。理解它们的实现原理、适用场景以及背后的设计思想不仅是应对面试“八股文”的必备技能更是写出高内聚、低耦合、易于扩展的优雅代码的基石。接下来我将结合十多年的实战经验带你彻底搞懂这两种代理并附上可直接运行的示例代码和避坑指南。2. 静态代理手写中介的得与失静态代理顾名思义代理关系在编译期就已经确定下来了。我们需要手动为每一个需要被代理的类编写一个对应的代理类。这种方式非常直观但灵活性较差。2.1 核心实现原理与示例静态代理的实现基于一个核心原则代理类和目标类实现同一个接口。这样客户端就可以面向接口编程而无须关心背后是代理还是真实对象。我们以一个简单的“用户服务”为例。假设有一个UserService接口定义了保存用户的方法。// 1. 定义共同接口 public interface UserService { void saveUser(String username); }接着实现真正的业务逻辑类也就是我们的目标对象。// 2. 实现目标对象真实对象 public class UserServiceImpl implements UserService { Override public void saveUser(String username) { // 模拟核心业务逻辑将用户信息存入数据库 System.out.println(核心业务将用户[ username ]保存到数据库...); // 这里可能会有复杂的数据库操作、校验等 try { Thread.sleep(100); // 模拟耗时操作 } catch (InterruptedException e) { e.printStackTrace(); } } }现在我们想在保存用户之前记录日志之后记录耗时。如果直接修改UserServiceImpl代码会变得混乱。更好的方式是创建一个代理类。// 3. 实现静态代理类 public class UserServiceStaticProxy implements UserService { // 持有目标对象的引用 private UserService target; // 通过构造器注入目标对象 public UserServiceStaticProxy(UserService target) { this.target target; } Override public void saveUser(String username) { // 前置增强记录日志 System.out.println([静态代理] 开始保存用户 username 时间 new Date()); long startTime System.currentTimeMillis(); // 调用目标对象的核心方法 target.saveUser(username); long endTime System.currentTimeMillis(); // 后置增强记录耗时 System.out.println([静态代理] 保存用户完成耗时 (endTime - startTime) ms); } }最后我们来看客户端如何调用// 4. 客户端调用 public class StaticProxyDemo { public static void main(String[] args) { // 创建真实对象 UserService realService new UserServiceImpl(); // 创建代理对象并将真实对象传入 UserService proxy new UserServiceStaticProxy(realService); // 调用代理对象的方法 proxy.saveUser(张三); } }运行上述代码你会看到如下输出[静态代理] 开始保存用户张三 时间Thu Nov 07 10:00:00 CST 2024 核心业务将用户[张三]保存到数据库... [静态代理] 保存用户完成耗时100ms可以看到我们成功地在不修改UserServiceImpl任何代码的情况下为它添加了日志和性能监控功能。2.2 静态代理的优缺点与适用场景优点直观易懂代码结构清晰代理类和目标类的关系一目了然非常适合教学和理解代理模式的基本思想。编译期检查由于代理类和目标类都实现了同一个接口任何方法签名的不匹配都会在编译期报错安全性高。无额外开销代理调用是直接的Java方法调用没有反射带来的性能损耗。缺点类爆炸这是静态代理最致命的缺点。如果系统中有100个Service需要加日志你就得手动编写100个几乎一模一样的代理类LoggingProxyForA,LoggingProxyForB...代码冗余度极高维护成本巨大。灵活性差一旦接口 (UserService) 发生变更比如增加了一个新方法deleteUser()那么不仅所有实现类要修改所有的静态代理类也必须同步修改否则编译就会失败。功能耦合代理逻辑如日志和代理目标如UserService在代码层面是硬编码在一起的。如果想为同一个服务更换另一种增强逻辑比如换成事务管理又得重新写一个代理类。适用场景静态代理通常只适用于代理类较少、且接口非常稳定的场景。在一些古老的系统或对性能有极致要求、且不能使用动态代理如早期Android开发的情况下可能会见到它的身影。但在现代Java开发中它更多地是作为理解动态代理的“垫脚石”。实操心得在实际项目中我几乎从未手动编写过静态代理类。它的教学意义远大于实用意义。当你理解了静态代理的繁琐才会真正体会到动态代理带来的解放。3. 动态代理运行时编织的魔法动态代理解决了静态代理的“类爆炸”问题。它的核心思想是在程序运行期间动态地在内存中生成代理类的字节码并创建代理对象。我们无需为每个目标类编写代理类只需要编写一个通用的“代理处理器”告诉JVM“请按照我的规则为这个接口生成一个代理对象”。Java提供了两种主流的动态代理实现方式基于JDK接口的动态代理和基于CGLIB库的类代理。3.1 JDK动态代理面向接口的优雅之选JDK动态代理是Java标准库 (java.lang.reflect包) 自带的特性。它有一个关键限制它只能为接口创建代理。这是因为JDK动态代理生成的代理类在运行时已经继承了java.lang.reflect.Proxy类Java是单继承所以只能通过实现目标接口的方式来实现代理。它的核心是java.lang.reflect.InvocationHandler接口。我们需要实现这个接口并在其唯一的invoke方法中定义通用的增强逻辑。import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import java.util.Date; // 1. 实现一个通用的调用处理器 public class LoggingInvocationHandler implements InvocationHandler { // 持有目标对象真实对象 private final Object target; public LoggingInvocationHandler(Object target) { this.target target; } /** * 代理对象任何方法的调用都会转发到这个 invoke 方法 * param proxy 代理对象本身通常很少直接使用它容易引发递归调用 * param method 被调用的方法对象 * param args 调用方法时传入的参数 * return 方法的返回值 */ Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 前置增强 System.out.println([JDK动态代理] 开始调用方法: method.getName() 参数: (args ! null ? args[0] : null) 时间: new Date()); long startTime System.currentTimeMillis(); // 利用反射调用目标对象的真实方法 Object result method.invoke(target, args); long endTime System.currentTimeMillis(); // 后置增强 System.out.println([JDK动态代理] 方法调用完成耗时: (endTime - startTime) ms); return result; // 返回真实方法的执行结果 } }接下来我们使用Proxy.newProxyInstance方法来创建代理对象。// 2. 客户端使用JDK动态代理 public class JdkDynamicProxyDemo { public static void main(String[] args) { // 1. 创建真实对象 UserService realService new UserServiceImpl(); // 2. 创建InvocationHandler InvocationHandler handler new LoggingInvocationHandler(realService); // 3. 使用Proxy类动态创建代理对象 UserService proxy (UserService) Proxy.newProxyInstance( realService.getClass().getClassLoader(), // 类加载器通常使用目标类的类加载器 realService.getClass().getInterfaces(), // 接口数组代理类需要实现的接口 handler // 调用处理器包含增强逻辑 ); // 4. 通过代理对象调用方法 proxy.saveUser(李四); // 可以打印一下代理对象的类型会发现它是一个奇怪的类名 System.out.println(代理对象的类名: proxy.getClass().getName()); // 输出类似com.sun.proxy.$Proxy0 } }运行结果与静态代理类似但代理对象是通过$Proxy0这样的类动态创建的。JDK动态代理的核心机制解析字节码生成Proxy.newProxyInstance方法在运行时会根据传入的接口数组利用字节码技术如sun.misc.ProxyGenerator动态生成一个代理类的字节码。这个类实现了你指定的所有接口。方法调用路由生成的代理类中每个接口方法如saveUser的内部实现都会统一调用你传入的InvocationHandler对象的invoke方法。这就是为什么所有方法的增强逻辑都集中在invoke方法中的原因。类加载生成的字节码会被一个特殊的类加载器加载到JVM中并实例化出代理对象。3.2 CGLIB动态代理突破接口限制的利器JDK动态代理必须要求目标对象实现接口那对于没有实现任何接口的普通类我们想代理它怎么办这时就需要用到CGLIB (Code Generation Library)。CGLIB是一个强大的、高性能的代码生成库它通过在运行时动态生成目标类的子类来实现代理。因为继承关系这个子类代理类自然就拥有了父类目标类的所有非final方法并可以重写这些方法来进行增强。首先需要引入CGLIB依赖以Maven为例dependency groupIdcglib/groupId artifactIdcglib/artifactId version3.3.0/version /dependency假设我们有一个没有实现接口的类// 一个没有实现任何接口的普通类 public class UserDao { public void save(String username) { System.out.println(UserDao: 保存用户[ username ]到数据库...); try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } } }使用CGLIB为其创建代理import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; import java.util.Date; // 1. 实现MethodInterceptor接口类似于JDK的InvocationHandler public class LoggingMethodInterceptor implements MethodInterceptor { /** * 拦截目标类所有方法的调用 * param obj 代理对象CGLIB生成的子类对象 * param method 被拦截的方法 * param args 方法参数 * param proxy 用于调用父类即目标类原始方法的代理 */ Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { // 前置增强 System.out.println([CGLIB代理] 开始调用方法: method.getName() 参数: (args ! null ? args[0] : null) 时间: new Date()); long startTime System.currentTimeMillis(); // 关键调用父类目标类的原始方法。 // 注意这里用的是 proxy.invokeSuper而不是 method.invoke。 Object result proxy.invokeSuper(obj, args); long endTime System.currentTimeMillis(); // 后置增强 System.out.println([CGLIB代理] 方法调用完成耗时: (endTime - startTime) ms); return result; } }创建代理对象并测试// 2. 客户端使用CGLIB动态代理 public class CglibDynamicProxyDemo { public static void main(String[] args) { // 1. 创建Enhancer对象CGLIB的字节码增强器 Enhancer enhancer new Enhancer(); // 2. 设置父类即要被代理的目标类 enhancer.setSuperclass(UserDao.class); // 3. 设置回调即我们的拦截器 enhancer.setCallback(new LoggingMethodInterceptor()); // 4. 创建代理对象 UserDao proxy (UserDao) enhancer.create(); // 5. 调用代理对象的方法 proxy.save(王五); System.out.println(代理对象的类名: proxy.getClass().getName()); // 输出类似com.example.UserDao$$EnhancerByCGLIB$$xxxxxxxx } }3.3 JDK代理 vs CGLIB代理如何选择这是一个经典的面试题和实战选型问题。我们可以从几个维度来对比特性维度JDK动态代理CGLIB动态代理代理目标只能代理实现了接口的类可以代理未实现接口的普通类实现原理通过反射机制实现接口生成代理类通过继承目标类生成子类作为代理类性能在JDK1.8及以后性能有显著优化通常与CGLIB相差无几。早期版本反射调用较慢。早期版本因直接调用FastClass避免反射而更快。现代JVM对反射优化很好两者性能差异已不显著。限制目标类必须有接口。无法代理final类和final/private/static方法因为无法被继承或重写。依赖JDK自带无需额外jar包。需要引入CGLIB库。生成类类名格式$ProxyN类名格式TargetClass$$EnhancerByCGLIB$$...选型建议如果目标对象实现了接口优先使用JDK动态代理。这是Java标准库的一部分无额外依赖符合面向接口编程的原则。Spring框架在目标有接口时默认也使用JDK代理。如果目标对象没有实现接口必须使用CGLIB代理。追求极致性能或需要代理非公有方法需要根据实际场景测试。对于大量、高频的方法调用CGLIB可能略有优势但绝大多数应用场景下两者的差异可以忽略不计。不要过早优化优先考虑代码的清晰度和可维护性。注意事项使用CGLIB时需要特别注意构造器调用和final方法的问题。如果目标类的构造方法不是默认无参构造或者目标类/方法被声明为finalCGLIB将无法正常工作。此外由于CGLIB通过生成子类来代理如果目标类中有一个方法内部调用了自己的另一个方法this.someOtherMethod()那么被调用的方法不会被代理拦截因为它是在目标对象内部发生的而不是通过代理对象。这是基于继承的代理的一个常见陷阱。4. 实战进阶动态代理在框架中的应用与原理深潜理解了基础原理后我们来看看动态代理如何在实际框架中大放异彩并深入一些高级话题。4.1 Spring AOP的基石Spring框架中面向切面编程AOP的核心实现就依赖于动态代理。当你使用Transactional,Cacheable等注解时Spring在背后默默为你创建了代理对象。默认策略如果目标Bean实现了接口Spring默认使用JDK动态代理。你可以通过proxy-target-class属性强制使用CGLIB。强制CGLIB如果目标Bean没有实现接口或者你设置了proxy-target-classtrueSpring会使用CGLIB代理。Spring将各种增强逻辑通知Advice封装到MethodInterceptor注意这是Spring AOP自己的接口不是CGLIB的的实现类中然后通过ProxyFactory这样的工厂类根据配置选择合适的代理方式JDK或CGLIB来创建最终的代理Bean。当你从Spring容器中获取一个被AOP管理的Bean时你拿到的实际上就是这个代理对象。4.2 手写一个简易的“事务代理”示例让我们结合JDK动态代理模拟一个非常简易的事务管理功能来感受一下AOP的思想。import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; import java.lang.reflect.Proxy; import java.sql.Connection; import java.sql.SQLException; // 模拟一个数据库操作接口 interface AccountDao { void transfer(String from, String to, int amount); } // 模拟真实实现这里省略了真实的JDBC代码 class AccountDaoImpl implements AccountDao { Override public void transfer(String from, String to, int amount) { System.out.println(执行转账SQL: 从 from 扣款 amount 向 to 加款 amount); // 这里应该执行两条update语句 } } // 事务管理的InvocationHandler class TransactionInvocationHandler implements InvocationHandler { private Object target; // 模拟一个数据库连接实际中可能从ThreadLocal获取 private Connection connection; public TransactionInvocationHandler(Object target, Connection connection) { this.target target; this.connection connection; } Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { Object result null; try { System.out.println(【事务代理】开启事务设置自动提交为false); connection.setAutoCommit(false); // 开启事务 // 调用真实业务方法 result method.invoke(target, args); System.out.println(【事务代理】提交事务); connection.commit(); // 提交事务 } catch (Exception e) { System.out.println(【事务代理】回滚事务原因: e.getMessage()); try { connection.rollback(); // 回滚事务 } catch (SQLException ex) { ex.printStackTrace(); } throw e; // 将异常继续抛出 } finally { try { connection.setAutoCommit(true); // 恢复自动提交 // connection.close(); // 实际中连接应由连接池管理 } catch (SQLException e) { e.printStackTrace(); } } return result; } } // 测试类 public class TransactionProxyDemo { public static void main(String[] args) throws SQLException { AccountDao realDao new AccountDaoImpl(); // 模拟一个数据库连接 Connection mockConnection new MockConnection(); // 假设有一个MockConnection InvocationHandler handler new TransactionInvocationHandler(realDao, mockConnection); AccountDao proxyDao (AccountDao) Proxy.newProxyInstance( realDao.getClass().getClassLoader(), realDao.getClass().getInterfaces(), handler ); // 测试正常情况 System.out.println( 测试正常转账 ); try { proxyDao.transfer(Alice, Bob, 100); } catch (Exception e) { System.out.println(捕获到异常: e.getMessage()); } // 测试异常情况模拟一个会抛出异常的业务方法 System.out.println(\n 测试异常转账 ); AccountDao realDaoWithError new AccountDaoImpl() { Override public void transfer(String from, String to, int amount) { super.transfer(from, to, amount); throw new RuntimeException(模拟第二次更新时数据库连接失败); } }; InvocationHandler handler2 new TransactionInvocationHandler(realDaoWithError, mockConnection); AccountDao proxyDaoWithError (AccountDao) Proxy.newProxyInstance( realDaoWithError.getClass().getClassLoader(), realDaoWithError.getClass().getInterfaces(), handler2 ); try { proxyDaoWithError.transfer(Alice, Bob, 100); } catch (Exception e) { System.out.println(捕获到异常: e.getMessage()); } } }这个示例虽然简陋但它清晰地展示了如何将横切关注点事务管理从核心业务逻辑转账SQL中剥离出来。通过动态代理我们实现了“事务”这个功能的模块化和复用。4.3 性能考量与最佳实践代理对象的创建成本动态代理无论是JDK还是CGLIB在第一次创建代理类时都有一定的开销因为它需要生成字节码并加载。但这个成本是一次性的。一旦代理类被创建并加载到JVM后续生成代理对象的开销就很小了。因此在Spring等容器中代理Bean通常是单例的创建开销可以忽略。方法调用的开销JDK代理通过反射调用Method.invoke。在现代JVM尤其是JDK 1.8中对反射调用有很好的优化如inflation机制会将反射调用编译成直接的字节码调用性能损耗很小。CGLIB代理通过生成FastClass来建立方法索引直接进行方法调用避免了反射理论上更快。但在实际中对于大部分应用这点差异微乎其微。最佳实践缓存代理对象避免在循环或高频调用处重复创建代理对象。谨慎使用CGLIB对final方法的代理明确知道哪些方法不会被代理避免出现逻辑错误。理解“自调用”问题在代理对象内部通过this调用另一个方法不会经过代理。这是AOP的一个常见问题通常的解决方法是① 避免自调用② 从Spring容器中重新获取代理对象来调用③ 使用AspectJ的编译时/加载时织入LTW来规避。5. 常见问题排查与深度思考在实际使用中你可能会遇到一些“诡异”的情况。这里记录几个我踩过的坑和对应的排查思路。5.1 问题一代理对象的方法没有被增强现象你明明配置了事务或日志的AOP但方法执行时没有任何增强效果。排查步骤检查Bean是否是代理对象在Spring中可以通过applicationContext.getBean(“beanName”).getClass()打印类名。如果看到$$EnhancerBySpringCGLIB$$或$Proxy字样说明是代理对象如果是原始类名则说明代理未生效。检查切入点表达式确认你的AOP配置中的Pointcut表达式是否正确匹配到了目标方法。检查方法可见性对于CGLIB代理private,final,static方法默认不会被代理。确保你的增强方法不是这些。检查“自调用”问题这是最隐蔽的一个坑。在同一个类中方法A调用方法B如果调用是通过this.methodB()进行的那么对方法B的增强不会生效。因为this指向的是目标对象本身而不是它的代理对象。5.2 问题二类型转换异常ClassCastException现象(SomeClass) applicationContext.getBean(“someBean”)抛出类型转换异常。原因与解决JDK代理代理对象实现的是接口而不是具体的实现类。如果你尝试将代理对象强制转换为具体的实现类如UserServiceImpl就会失败。应该始终转换为接口类型UserService。CGLIB代理代理对象是目标类的子类所以可以强制转换为目标类。但为了代码的通用性和清晰性也推荐转换为接口类型。最佳实践遵循“面向接口编程”原则。在注入或获取Bean时使用接口类型。Spring的Autowired默认按类型注入如果只有一个实现它会自动找到代理Bean并注入接口。5.3 问题三如何判断一个对象是否是代理对象有时在调试或写工具类时需要判断一个对象是否是Spring代理。import org.springframework.aop.support.AopUtils; public class ProxyCheckUtil { public static void check(Object bean) { // 是否是Spring AOP代理 boolean isAopProxy AopUtils.isAopProxy(bean); // 是否是CGLIB代理 boolean isCglibProxy AopUtils.isCglibProxy(bean); // 是否是JDK动态代理 boolean isJdkDynamicProxy AopUtils.isJdkDynamicProxy(bean); System.out.println(isAopProxy: isAopProxy); System.out.println(isCglibProxy: isCglibProxy); System.out.println(isJdkDynamicProxy: isJdkDynamicProxy); // 获取目标类被代理的原始类 if (isAopProxy) { Class? targetClass AopUtils.getTargetClass(bean); System.out.println(Target class: targetClass.getName()); } } }5.4 动态代理的底层是如何生成类的这是一个更深入的话题。无论是JDK的ProxyGenerator还是CGLIB的Enhancer其本质都是操作字节码。JDKsun.misc.ProxyGenerator类在JDK内部会生成一个实现了所有指定接口的.class文件的字节数组。这个类有一个静态代码块通过反射初始化所有Method对象并且每个接口方法都长这样public final void saveUser(String var1) { try { super.h.invoke(this, m3, new Object[]{var1}); // m3就是Method对象 } catch (...) { ... } }其中h就是你传入的InvocationHandler。CGLIB使用ASM一个Java字节码操作框架直接生成新的.class文件。它会创建目标类的子类并重写非final方法。重写的方法体里会调用你注册的MethodInterceptor的intercept方法。理解到这个层次你就能明白为什么动态代理如此强大也为什么会有前面提到的那些限制如final方法不能被CGLIB重写。我个人在长期使用动态代理的过程中最大的体会是它不仅仅是一个技术更是一种强大的设计思想。它把“做什么”核心业务和“在什么时机、以什么方式做”横切逻辑完美地解耦了。当你掌握了它再看Spring的声明式事务、MyBatis的插件机制、RPC框架的调用拦截甚至是一些中间件的实现都会有一种豁然开朗的感觉。从最初死记硬背“JDK基于接口CGLIB基于继承”的面试答案到后来在架构设计中游刃有余地运用代理模式来解决实际问题这个过程本身就是一次思维的升级。下次当你需要为系统添加全局的权限校验、数据脱敏或调用链跟踪时不妨先想一想是不是可以用一个优雅的动态代理来实现