1. 从“远程桌面服务即将停止”说起：为什么我们需要代理？

前几天，一个朋友在群里发了一张截图，上面赫然写着：“远程桌面授权模式尚未配置，远程桌面服务将在 118 天后停止工作。” 他问我这是怎么回事。我一看就乐了，这其实是一个典型的“代理”问题——只不过这里的“代理”是 Windows 系统里负责处理远程桌面连接授权的“RD 连接代理”服务。这个服务就像一个“中介”，负责验证和转发用户的连接请求到正确的远程桌面主机。如果这个“中介”（代理）配置不当或者失效了，整个远程桌面服务就会出问题。

这让我想到，在软件设计里，“代理模式”扮演着几乎一模一样的角色。它也是一个“中介”，一个“替身”，或者一个“包装器”。当你不能、不想或者不方便直接访问某个对象时，代理就出场了。它帮你处理那些繁琐的、重复的、或者需要额外控制的事情，比如权限检查、日志记录、性能监控、延迟初始化等等，让你能更“纯粹”地关注核心业务逻辑。

今天，我们就来彻底搞懂 Java 世界里两种最核心的代理实现：静态代理和动态代理。无论你是刚接触设计模式的新手，还是想深入理解 Spring AOP 底层原理的老鸟，这篇文章都会带你从“是什么”、“为什么”到“怎么用”，并最终落脚到“如何选”，让你不仅会用，更能理解其背后的设计哲学和实现细节。我们尤其会聚焦于 JDK 动态代理和 CGLIB 这两种在框架中（比如 Spring AOP）至关重要的技术，剖析它们的区别与选择策略。

2. 静态代理：手把手打造一个专属“中介”

静态代理，顾名思义，就是在编译期就确定下来的代理关系。我们需要手动为每一个被代理的类编写一个对应的代理类。这种方式非常直观，就像你为了办一件事，专门雇了一个私人助理。

2.1 核心角色与 UML 图解

在深入代码之前，我们先通过一个经典的场景来理解静态代理中的几个核心角色。假设我们有一个“数据查询”服务，现在需要为这个服务添加执行耗时统计的功能。

1. 抽象主题（Subject）：定义了被代理对象和代理对象的共同接口。这样，客户端就可以像使用真实对象一样使用代理对象。这通常是一个接口。
2. 真实主题（Real Subject）：真正执行业务逻辑的对象，也就是被代理的对象。
3. 代理（Proxy）：持有对真实主题的引用，并在其接口方法被调用时，可以附加额外的操作（如日志、鉴权），然后再将请求转发给真实主题。

它们的关系用 UML 类图表示非常简单：代理类和真实类都实现同一个接口，并且代理类内部包含一个真实类的实例引用。

2.2 一个完整的代码示例：为数据查询添加耗时监控

让我们用代码来具象化这个过程。首先，定义我们的抽象主题——DataService接口。

// 1. 抽象主题 (Subject) public interface DataService { String queryData(String param); void updateData(String data); }

接着，创建真实主题——真正干活的DataServiceImpl。

// 2. 真实主题 (Real Subject) public class DataServiceImpl implements DataService { @Override public String queryData(String param) { // 模拟一个耗时的数据库查询 try { Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } return “查询结果: ” + param; } @Override public void updateData(String data) { // 模拟数据更新操作 System.out.println(“更新数据: ” + data); } }

现在，关键来了。我们不希望修改DataServiceImpl的代码（遵循“开闭原则”），但又想给它的每个方法加上执行时间统计。这时，静态代理类DataServiceProxy就派上用场了。

// 3. 代理 (Proxy) public class DataServiceProxy implements DataService { // 持有真实主题的引用 private DataService realService; public DataServiceProxy(DataService realService) { this.realService = realService; } @Override public String queryData(String param) { long start = System.currentTimeMillis(); // 转发请求给真实对象 String result = realService.queryData(param); long end = System.currentTimeMillis(); System.out.println(“queryData 方法执行耗时: ” + (end - start) + “ms”); return result; } @Override public void updateData(String data) { long start = System.currentTimeMillis(); // 转发请求给真实对象 realService.updateData(data); long end = System.currentTimeMillis(); System.out.println(“updateData 方法执行耗时: ” + (end - start) + “ms”); } }

最后，看看客户端如何调用：

public class Client { public static void main(String[] args) { // 创建真实对象 DataService realService = new DataServiceImpl(); // 创建代理对象，并将真实对象传入 DataService proxy = new DataServiceProxy(realService); // 客户端通过代理对象调用方法，完全无感知 String data = proxy.queryData(“testParam”); System.out.println(data); proxy.updateData(“newData”); } }

运行这段代码，你会在控制台看到类似这样的输出：

queryData 方法执行耗时: 101ms 查询结果: testParam 更新数据: newData updateData 方法执行耗时: 0ms

注意：这里updateData的耗时是 0ms，是因为Thread.sleep只存在于queryData中。这个细节恰恰说明了代理的透明性——它只负责增强，不改变原有逻辑。

2.3 静态代理的优缺点与适用场景

优点：

1. 直观清晰：代理类和被代理类的关系一目了然，符合面向对象的设计思想。
2. 无侵入性：可以在不修改目标对象代码的前提下，扩展其功能。
3. 职责清晰：将核心业务逻辑（DataServiceImpl）与横切关注点（如日志、监控，在DataServiceProxy中）分离。

缺点：

1. 类爆炸：如果系统中有大量需要代理的类或者接口方法很多，你就需要编写大量的代理类，导致项目臃肿，难以维护。想象一下，如果有 50 个服务类需要加日志，你就得写 50 个几乎雷同的代理类。
2. 紧耦合：代理类和被代理类在编译期就绑定在一起。如果接口 (DataService) 发生变更，比如增加了一个新方法，那么所有实现了该接口的代理类都必须跟着修改，违反了“对修改关闭”的原则。
3. 灵活性差：增强逻辑（如这里的耗时统计）是硬编码在代理类中的。如果想动态地、按需地为不同方法添加不同的增强（比如只对queryData做缓存，对updateData做事务管理），静态代理就显得力不从心。

适用场景：静态代理适用于代理类较少、接口稳定、增强逻辑简单且固定的场景。例如，在早期的小型项目或某些工具类中，为少数几个核心服务类添加统一的日志或权限控制，使用静态代理是简单有效的。

3. 动态代理：运行时“凭空”创造代理对象

动态代理就是为了解决静态代理的“类爆炸”和“灵活性差”而生的。它的核心思想是：在程序运行期间，动态地在内存中创建代理类及其对象，而无需手动编写源代码。Java 主要提供了两种主流的动态代理机制：基于接口的 JDK 动态代理和基于继承的 CGLIB 动态代理。

3.1 JDK 动态代理：基于接口的“契约”代理

JDK 动态代理是 Java 标准库 (java.lang.reflect) 自带的。它有一个关键限制：它只能为接口创建代理。这是因为它的原理是在运行时动态生成一个实现了指定接口的新类。

3.1.1 核心组件：InvocationHandler

InvocationHandler是 JDK 动态代理的灵魂。它是一个调用处理器接口，我们只需要实现它的invoke方法。所有对代理对象方法的调用，都会被 JVM 路由到这个invoke方法中。

public interface InvocationHandler { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable; }

• proxy: 动态生成的代理对象本身（通常在这个方法里用不到，慎用，否则可能引起递归调用）。
• method: 当前被调用的方法对象（Method实例）。
• args: 调用方法时传入的参数。

我们的增强逻辑（如日志、事务）就写在invoke方法里，并通过method.invoke(target, args)来调用原始目标对象的方法。

3.1.2 完整实现：用 JDK 动态代理重构耗时监控

让我们用 JDK 动态代理来实现和之前静态代理一样的功能。

首先，实现一个通用的InvocationHandler：

import java.lang.reflect.InvocationHandler; import java.lang.reflect.Method; public class TimingInvocationHandler implements InvocationHandler { // 持有真实目标对象 private final Object target; public TimingInvocationHandler(Object target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { long start = System.currentTimeMillis(); // 调用真实对象的方法 Object result = method.invoke(target, args); long end = System.currentTimeMillis(); System.out.println(method.getName() + “ 方法执行耗时: ” + (end - start) + “ms”); return result; } }

然后，在客户端通过Proxy.newProxyInstance来创建代理对象：

import java.lang.reflect.Proxy; public class JdkDynamicProxyClient { public static void main(String[] args) { // 1. 创建真实对象 DataService realService = new DataServiceImpl(); // 2. 创建 InvocationHandler InvocationHandler handler = new TimingInvocationHandler(realService); // 3. 动态创建代理对象 DataService proxy = (DataService) Proxy.newProxyInstance( realService.getClass().getClassLoader(), // 类加载器 new Class[]{DataService.class}, // 代理需要实现的接口数组 handler // 调用处理器 ); // 4. 使用代理对象 System.out.println(proxy.queryData(“dynamicParam”)); proxy.updateData(“dynamicData”); // 打印代理对象的类名（很有趣！） System.out.println(“代理对象的类是：” + proxy.getClass().getName()); } }

运行后，输出效果和静态代理一致，但最后一行会打印出类似$Proxy0这样的类名。这就是 JVM 在运行时为我们动态生成的代理类，它实现了DataService接口。

3.1.3 底层原理浅析与注意事项

当你调用Proxy.newProxyInstance时，JDK 内部大致做了以下几件事：

1. 根据传入的接口数组，在内存中动态生成一个类的字节码。这个类会实现所有这些接口。
2. 这个生成的类（如$Proxy0）的每个方法内部，逻辑都差不多：调用我们传入的InvocationHandler的invoke方法。
3. 使用传入的ClassLoader将这个字节码加载到 JVM 中。
4. 利用反射 API 创建这个新类的实例，并将其返回。

重要提示：由于 JDK 动态代理是基于接口的，所以被代理的目标对象必须至少实现一个接口。如果你尝试代理一个没有实现任何接口的普通类，Proxy.newProxyInstance会抛出IllegalArgumentException。

3.2 CGLIB 动态代理：基于继承的“子类”代理

CGLIB (Code Generation Library) 是一个强大的、高性能的代码生成库。它通过继承的方式来实现代理。因此，它可以为没有实现接口的普通类创建代理。Spring AOP 在目标对象没有实现接口时，默认就使用 CGLIB。

3.2.1 核心组件：MethodInterceptor

CGLIB 的核心是MethodInterceptor接口，它的作用和 JDK 的InvocationHandler类似。

public interface MethodInterceptor extends Callback { Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable; }

• obj: 动态生成的代理对象（CGLIB 增强后的子类对象）。
• method: 被拦截的方法（目标类的方法）。
• args: 方法参数。
• proxy: 用于调用父类（即原始目标类）方法的代理方法。强烈建议使用proxy.invokeSuper(obj, args)而不是method.invoke(target, args)，因为前者直接调用字节码，性能更高，且能避免某些递归问题。

3.2.2 完整实现：用 CGLIB 代理普通类

首先，我们需要一个没有接口的普通类作为目标：

// 一个没有实现任何接口的普通类 public class ConcreteDataService { public String findData(String id) { try { Thread.sleep(80); } catch (InterruptedException e) { e.printStackTrace(); } return “Concrete Data for ” + id; } public final void finalMethod() { System.out.println(“这是一个 final 方法，无法被代理增强。”); } }

然后，实现MethodInterceptor：

import net.sf.cglib.proxy.MethodInterceptor; import net.sf.cglib.proxy.MethodProxy; import java.lang.reflect.Method; public class CglibTimingInterceptor implements MethodInterceptor { @Override public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable { // 可以在这里进行方法过滤，例如不代理 final 方法或 toString 等方法 if (“finalMethod”.equals(method.getName())) { return proxy.invokeSuper(obj, args); // 直接调用，不加增强 } long start = System.currentTimeMillis(); // 使用 MethodProxy.invokeSuper 调用父类（目标类）方法，性能更好 Object result = proxy.invokeSuper(obj, args); long end = System.currentTimeMillis(); System.out.println(“CGLIB - ” + method.getName() + “ 方法执行耗时: ” + (end - start) + “ms”); return result; } }

最后，使用Enhancer类创建代理：

import net.sf.cglib.proxy.Enhancer; public class CglibDynamicProxyClient { public static void main(String[] args) { // 1. 创建 Enhancer 对象，相当于 JDK Proxy 的工厂类 Enhancer enhancer = new Enhancer(); // 2. 设置父类（即要被代理的类） enhancer.setSuperclass(ConcreteDataService.class); // 3. 设置回调（即我们的 MethodInterceptor） enhancer.setCallback(new CglibTimingInterceptor()); // 4. 创建代理对象（注意：这里创建的是目标类的子类对象） ConcreteDataService proxy = (ConcreteDataService) enhancer.create(); // 5. 使用代理对象 System.out.println(proxy.findData(“123”)); proxy.finalMethod(); // 这个方法不会被增强 System.out.println(“代理对象的类是：” + proxy.getClass().getName()); System.out.println(“代理对象的父类是：” + proxy.getClass().getSuperclass().getName()); } }

运行后，你会看到findData方法被增强了，而finalMethod则没有。同时，打印的类名会是类似ConcreteDataService$$EnhancerByCGLIB$$xxxxxxxx这样的形式，这正是 CGLIB 生成的子类。

3.2.3 CGLIB 的限制与性能考量

1. 无法代理 final 类或 final 方法：因为 CGLIB 通过生成子类来工作，所以对于 final 修饰的类或方法，它无能为力。
2. 构造函数调用：代理对象的创建会调用两次目标类的构造函数？这是一个常见的误解。实际上，CGLIB 生成的子类在实例化时，会调用一次父类的无参构造函数（如果存在的话，这是 Java 对象初始化的标准流程），然后我们通过enhancer.create()创建的是这个子类的实例。目标对象本身（父类实例）并没有被额外创建一次。增强逻辑发生在子类重写的方法里。
3. 性能：在早期版本中，CGLIB 生成的代理对象在方法调用上可能比 JDK 动态代理稍慢，因为涉及到继承层次和方法重写。但随着 JVM 优化和 CGLIB 自身的改进，这个差距已经很小，甚至在很多场景下 CGLIB 更快，因为它直接操作字节码，而 JDK 代理需要反射调用。Spring 等框架通常会对生成的代理类进行缓存，以最大化性能。

4. JDK 动态代理 vs CGLIB：深入对比与框架选型

这是面试和实际框架使用中最常被问到的问题。它们的区别远不止“一个基于接口，一个基于继承”这么简单。

4.1 本质区别对比表

4.2 Spring AOP 的默认选择与配置

Spring AOP 作为应用最广泛的 AOP 实现，其底层就是基于动态代理。它的选择策略是：

1. 默认策略（Spring 4.x / 5.x+）：

   • 如果目标对象实现了至少一个接口，则默认使用JDK 动态代理。
   • 如果目标对象没有实现任何接口，则默认使用CGLIB。

2. 强制使用 CGLIB： 你可以在 Spring 配置中强制使用 CGLIB，即使目标类实现了接口。这样做通常是为了代理类上的方法（而不仅仅是接口方法），或者是为了获得更好的性能（在某些历史版本或特定场景下）。

   • XML 配置：<aop:aspectj-autoproxy proxy-target-class=“true”/>
   • 注解配置：@EnableAspectJAutoProxy(proxyTargetClass = true)

3. 性能与“坑”：

   • 代理内部方法调用：这是 Spring AOP 一个经典的“坑”。在同一个类中，一个方法 A 调用另一个方法 B，即使 B 方法上有@Transactional或@Cacheable等注解，其增强也不会生效。因为 A 调用 B 是this.b()的直接调用，绕过了代理对象。解决方法通常是自我注入 (@Autowired注入自身) 或从 AOP 上下文获取代理对象。
   • CGLIB 与构造函数：由于 CGLIB 是继承，代理类实例化时会调用父类的构造函数。如果目标类的构造函数有复杂的初始化逻辑或副作用，需要注意。

4.3 如何选择？一个实战决策流程图

面对一个具体的增强需求，你应该如何选择代理方式？可以遵循以下思路：

开始 | v 目标对象是否有接口？ | | 是 否 | | v v 考虑因素： 必须使用 CGLIB | v 是否需要代理类自身的方法（非接口方法）？ | | 是 否 | | v v 选择 CGLIB 考虑因素： | v 目标类或方法是否为 final？ | | 是 否 | | v v 无法代理/重构代码 优先选择 JDK 动态代理 | （更标准，依赖少） v 结束

简单来说：

• 有接口，且只关心接口方法->JDK 动态代理。这是最纯粹、最符合面向接口编程原则的方式。
• 无接口，或需要代理类自身的特定方法->CGLIB。
• 对 final 类或方法有增强需求-> 这是一个设计警讯，可能需要重构代码，因为代理模式无法在此生效。

5. 超越基础：动态代理的高级应用与模式变体

理解了基本原理后，动态代理的能力远不止加个日志这么简单。它为实现许多高级设计模式和应用提供了底层支持。

5.1 实现延迟初始化（虚拟代理）

虚拟代理用于控制访问一个创建开销很大的对象。例如，加载一个高分辨率图片，在图片真正加载完成前，先显示一个占位符。

// 接口 public interface ExpensiveObject { void process(); } // 真实对象（创建成本高） public class ExpensiveObjectImpl implements ExpensiveObject { public ExpensiveObjectImpl() { // 模拟昂贵的初始化，如加载大文件、建立网络连接 heavyInitialConfiguration(); System.out.println(“ExpensiveObjectImpl 被真实创建了。”); } private void heavyInitialConfiguration() { try { Thread.sleep(2000); } catch (InterruptedException e) { e.printStackTrace(); } } @Override public void process() { System.out.println(“处理业务逻辑...”); } } // 虚拟代理 public class VirtualProxyHandler implements InvocationHandler { private ExpensiveObject realObject; // 开始为 null @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 在第一次调用时，才初始化真实对象 if (realObject == null) { realObject = new ExpensiveObjectImpl(); } // 将调用委托给真实对象 return method.invoke(realObject, args); } } // 客户端使用 public class Client { public static void main(String[] args) { ExpensiveObject proxy = (ExpensiveObject) Proxy.newProxyInstance( Client.class.getClassLoader(), new Class[]{ExpensiveObject.class}, new VirtualProxyHandler() ); System.out.println(“代理对象已创建（真实对象尚未创建）...”); // 直到调用 process 方法，真实对象才会被创建 proxy.process(); } }

5.2 实现远程代理（RPC/Stub的基石）

远程代理是 RPC（远程过程调用）框架的基石。本地存根（Stub）就是一个代理对象，它负责将方法调用及其参数序列化，通过网络发送给远程服务端，接收结果并反序列化返回给客户端。Dubbo、gRPC 等框架的客户端接口本质上就是通过动态代理（通常是 JDK 动态代理）实现的。

// 一个简化的模拟 public class RemoteServiceProxy implements InvocationHandler { private String host; private int port; public RemoteServiceProxy(String host, int port) { this.host = host; this.port = port; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 1. 序列化方法名、参数类型、参数值 String methodName = method.getName(); Class<?>[] parameterTypes = method.getParameterTypes(); // 使用 JSON、Hessian、Protobuf 等序列化 args... String requestBody = serialize(methodName, parameterTypes, args); // 2. 通过网络发送请求（简化为打印） System.out.println(“发送请求到 ” + host + “:” + port + “, 内容: ” + requestBody); // 实际代码会使用 HttpClient、Netty 等 // 3. 模拟接收响应并反序列化 String simulatedResponse = “{‘result’: ‘remote data’}”; Object result = deserialize(simulatedResponse, method.getReturnType()); return result; } // 省略序列化/反序列化方法... }

5.3 实现保护代理与智能引用

保护代理可以控制对真实对象的访问权限。智能引用代理可以在访问真实对象时附加一些内务操作，例如：

• 引用计数：记录对象被引用的次数，当计数为0时自动释放资源。
• 线程安全锁：在调用真实对象的方法前加锁，调用后释放。
• 缓存：第一次调用时缓存结果，后续调用直接返回缓存。

// 一个简单的缓存代理示例 public class CacheInvocationHandler implements InvocationHandler { private Map<String, Object> cache = new ConcurrentHashMap<>(); private Object target; public CacheInvocationHandler(Object target) { this.target = target; } @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { // 只为 ‘getXXX’ 方法添加缓存 if (method.getName().startsWith(“get”)) { String cacheKey = generateCacheKey(method, args); Object cachedValue = cache.get(cacheKey); if (cachedValue != null) { System.out.println(“从缓存获取数据: ” + cacheKey); return cachedValue; } Object result = method.invoke(target, args); cache.put(cacheKey, result); System.out.println(“存入缓存: ” + cacheKey); return result; } // 非 get 方法直接调用 return method.invoke(target, args); } private String generateCacheKey(Method method, Object[] args) { /* 生成唯一键 */ } }

6. 实战避坑指南：动态代理的那些“坑”与最佳实践

在实际项目中应用动态代理，尤其是结合 Spring 等框架时，会遇到一些典型问题。了解它们能让你少走弯路。

6.1 “this” 调用导致的增强失效

这是 Spring AOP 中最常见的问题之一。

@Service public class UserServiceImpl implements UserService { public void methodA() { System.out.println(“执行 methodA”); this.methodB(); // 问题在这里！直接调用了 this.methodB() } @Transactional // 假设有事务注解 public void methodB() { System.out.println(“执行 methodB”); } }

当你从外部调用userService.methodA()时，methodA内部的this.methodB()调用的是UserServiceImpl这个原始对象上的方法，而不是经过 Spring 代理（可能是 JDK 或 CGLIB 生成）后的对象。因此，methodB上的@Transactional注解会失效。

解决方案：

1. 自我注入（推荐）：Spring 可以通过注入自身代理来解决循环依赖，但需要开启@EnableAspectJAutoProxy(exposeProxy = true)。

   @Service public class UserServiceImpl implements UserService { @Autowired private UserService selfProxy; // 注入代理后的自己 public void methodA() { System.out.println(“执行 methodA”); selfProxy.methodB(); // 通过代理调用 } @Transactional public void methodB() { ... } }

2. 从 AopContext 获取当前代理（需暴露代理）：

   @EnableAspectJAutoProxy(exposeProxy = true) @Configuration public class AppConfig { ... } // 在方法中 UserService proxy = (UserService) AopContext.currentProxy(); proxy.methodB();

3. 重构设计：将methodB抽到另一个 Service 中，通过服务间调用来触发代理。

6.2 代理对象的类型识别与相等性判断

由于代理对象是运行时生成的类，它的getClass()和原始目标类不同。这会影响instanceof操作和某些依赖类类型的操作。

DataService real = new DataServiceImpl(); DataService jdkProxy = createJdkProxy(real); System.out.println(real instanceof DataService); // true System.out.println(jdkProxy instanceof DataService); // true (因为它实现了接口) System.out.println(real.getClass()); // class com.example.DataServiceImpl System.out.println(jdkProxy.getClass()); // class com.sun.proxy.$Proxy0 System.out.println(real.getClass().equals(jdkProxy.getClass())); // false // 对于 CGLIB 代理 ConcreteDataService cglibProxy = createCglibProxy(); System.out.println(cglibProxy instanceof ConcreteDataService); // true (因为它是子类) System.out.println(cglibProxy.getClass()); // class com.example.ConcreteDataService$$EnhancerByCGLIB$$...

最佳实践：

• 在业务逻辑中，尽量避免直接依赖具体的类类型进行比较。更多地依赖接口和多态。
• 如果必须判断，Spring 提供了AopUtils工具类来帮助识别代理：

  import org.springframework.aop.support.AopUtils; // 判断是否是代理 AopUtils.isAopProxy(myBean); // 判断是否是 JDK 动态代理 AopUtils.isJdkDynamicProxy(myBean); // 判断是否是 CGLIB 代理 AopUtils.isCglibProxy(myBean); // 获取原始目标类 Class<?> targetClass = AopUtils.getTargetClass(myBean);

6.3 性能考量与代理类缓存

虽然动态代理在运行时生成类会有一些开销，但这在绝大多数应用场景中都是微不足道的。真正的性能考量点在于：

1. 代理类创建开销：每次调用Proxy.newProxyInstance或Enhancer.create()都会生成新的代理类（字节码）并加载。务必避免在循环或高频调用中创建代理。
2. 框架级缓存：像 Spring 这样的框架，在容器启动时就会为需要代理的 Bean 创建好代理对象，并将其缓存起来。整个应用生命周期内，我们使用的都是同一个缓存的代理实例。所以，代理创建的开销通常是一次性的，在启动时完成。
3. 方法调用开销：JDK 动态代理通过反射调用InvocationHandler.invoke，而 CGLIB 通过 FastClass 机制直接调用方法，后者通常更快。但在现代 JVM 上，尤其是 JDK 1.8 之后，这个差距已经非常小，不应作为首要选型依据。

建议：在性能敏感的底层代码（如每秒处理数十万次的工具方法）中，谨慎使用重量级的代理增强。对于普通的业务服务层（Service），动态代理的开销完全可以接受。

6.4 调试与日志：看清代理的本质

当代理行为不符合预期时，调试可能会有点棘手，因为你看到的对象类型是代理类。以下技巧有助于调试：

1. 打印对象类名：如我们之前所做的，System.out.println(proxy.getClass().getName())可以立刻告诉你这是 JDK 代理 ($Proxy) 还是 CGLIB 代理 ($$EnhancerByCGLIB$$)。
2. 使用 IDE 调试器：在调试时，可以查看代理对象的字段。JDK 代理对象内部有一个h字段，指向InvocationHandler；CGLIB 代理对象内部有CGLIB$CALLBACK_0等字段，指向MethodInterceptor。顺着这些引用就能找到你自定义的增强逻辑。
3. 开启 Spring 调试日志：在application.properties中设置logging.level.org.springframework.aop=DEBUG，可以看到 Spring AOP 创建代理的详细过程。

动态代理是 Java 高级编程和框架设计中不可或缺的一环。从简单的日志增强，到复杂的 RPC、事务管理、安全控制，其身影无处不在。理解静态代理与动态代理，特别是 JDK 动态代理与 CGLIB 的原理、区别与适用场景，不仅能让你更好地使用 Spring 等框架，更能让你具备设计和实现类似灵活性架构的能力。下次当你再看到“远程桌面连接代理”或者任何“代理”这个词时，希望你能会心一笑，想起背后这套优雅而强大的设计模式。