一、先搞清楚：开销从哪里来

Spring AOP 的底层是动态代理，运行时才创建代理对象。这意味着每一次方法调用，都不是直接跳转到目标方法，而是要经过一层拦截、一层转发。开销就藏在这"多出来的一层"里。

具体来说，损耗来自四个环节：

第一，代理对象创建。 Spring 容器启动时，要为每个符合切点条件的 Bean 生成一个代理。JDK 动态代理通过反射构建代理类，CGLIB 则通过字节码生成子类。这个过程涉及类加载和字节码操作，首次创建代理对象的耗时是直接创建对象的 5 到 10 倍。

第二，方法拦截与调用链构建。 每次调用代理方法时，框架需要找出所有匹配当前方法的通知，构建成一条拦截器链。这个过程虽经高度优化，但仍有计算成本。

第三，反射调用或字节码转发。 JDK 动态代理最终通过 Method.invoke() 反射调用目标方法，比直接调用慢；CGLIB 虽然用 FastClass 机制避免了反射，但 FastClass 本身的索引查找也有开销。

第四，通知链的串联执行。 如果一个方法被 5 个 @Before 通知增强，就意味着目标方法前后要额外执行 5 段逻辑，耗时呈线性增长。

这四个环节中，前两个是启动时的一次性成本，后两个是每次调用都要付出的代价。真正拉开差距的，是后两个。

二、冷启动与热调用：两组关键实测数据

基于 JDK 17 环境，对 1000 次方法调用进行耗时测试，结果如下：

数据揭示了一个反直觉的结论：CGLIB 创建代理更快，但调用更慢；JDK 动态代理创建更慢，但调用更快。

原因在于底层机制的差异。CGLIB 用 ASM 框架直接生成字节码，创建过程是"一锤子买卖"，生成完就结束，所以首次创建速度反而优于 JDK。但在方法调用时，CGLIB 依赖 FastClass 机制，通过索引查找方法位置，这个查找过程比 JDK 代理经过 JIT 优化后的反射调用还要慢一截。

在 JDK 8 环境下进行一千万次调用的基准测试，结果更能说明问题：JDK 动态代理总耗时 152836ms，CGLIB 总耗时 154783ms。差距约 1.2%，几乎可以视为噪声。但请注意——这是在单一方法、无复杂通知链的理想条件下测得的。一旦叠加多个切面，差距会迅速拉大。

而在高频调用场景（每秒超过 100 万次）下，CGLIB 配合 FastClass 的调用速度反而比 JDK 代理快 30% 到 40%。这是因为 JDK 代理的反射调用在极高频率下，JIT 优化的收益会被方法调用本身的开销稀释，而 CGLIB 的字节码直调在这种场景下展现出了优势。

三、内存开销：一个被忽视的隐形杀手

性能不只是速度，还有内存。

JDK 动态代理生成的代理类数量相对可控，因为代理类可以被缓存和复用，且代理对象本身只持有接口引用，内存占用较低。实测数据显示，在大量短期对象的场景下，JDK 动态代理的内存占用比 CGLIB 低 20% 到 25%。

CGLIB 则是另一番景象。它为每个目标类生成一个子类，子类中包含了方法的 FastClass 索引、回调数组等额外结构。更致命的是，CGLIB 生成的类会被加载到 Metaspace（元空间），如果项目中有大量不同的切面组合，或者频繁修改切面配置，Metaspace 会快速膨胀。

某金融交易系统的真实案例：项目中大量 Service 类被多个 AOP 切面增强，默认使用 CGLIB 代理。高并发运行一段时间后，Metaspace 持续增长不释放，最终触发 Metaspace OOM，Full GC 频繁发作，应用响应时间从 20 毫秒劣化到 200 毫秒以上。排查后发现，根本原因就是 CGLIB 动态生成了过多字节码类，把元空间撑爆了。

这个案例告诉我们：CGLIB 的内存开销不是线性的，而是随切面数量和代理对象数量呈指数级增长。

四、真实场景下的性能对比

抛开实验室数据，来看几个真实业务场景中的表现。

场景一：高频方法调用（每秒超百万次）

推荐方案：CGLIB 配合 FastClass。调用速度比 JDK 代理快 30% 到 40%。因为在这种极端频率下，反射调用的 overhead 被放大，而 CGLIB 的字节码直调更占优势。

场景二：大量短期对象

推荐方案：JDK 动态代理。内存占用低 20% 到 25%，GC 压力小。适合对象创建频繁、生命周期短的场景，比如 Web 应用中的请求处理对象。

场景三：需要代理 final 类或 final 方法

推荐方案：Objenesis 配合 CGLIB。普通 CGLIB 无法代理 final 方法，但 Objenesis 可以绕过构造器限制，实现对 final 类的代理。这是唯一的选择。

场景四：云原生环境 / GraalVM 原生镜像

推荐方案：JDK 动态代理。启动时间可缩短 50% 以上。CGLIB 在原生镜像中的兼容性较差，字节码生成可能触发异常，而 JDK 代理作为 JVM 原生机制，天然适配。

五、Spring 的默认选择逻辑

Spring 并不是让你二选一，而是有一套智能决策机制。

在 DefaultAopProxyFactory 的 createAopProxy 方法中，框架会依次检查：目标类是否是接口、是否配置了 optimize 标志、是否设置了 proxyTargetClass。决策优先级如下：

如果目标类实现了接口，默认使用 JDK 动态代理；如果目标类没有接口，自动切换到 CGLIB；如果显式设置了 proxyTargetClass=true，全局强制使用 CGLIB。

这个默认策略的设计逻辑是：有接口就用 JDK，没接口才用 CGLIB。 原因很简单——JDK 代理是 JVM 原生支持，无需额外依赖，且在大多数场景下性能更优。Spring 6.0 之后对 JDK 动态代理的反射调用进行了深度优化，通过 MethodHandle 缓存机制将调用耗时降低了约 40%，进一步拉大了与 CGLIB 在常规场景下的差距。

但这个默认策略有一个隐蔽的坑：当你在接口上定义了 @Transactional，同时在实现类的方法上也加了 @Transactional，使用 JDK 代理时，只有接口上的注解会生效，实现类上的会被忽略。 而切换到 CGLIB 后，实现类上的注解才会被正确识别。这个差异曾导致多个生产事故——事务边界在不知不觉中发生了偏移。

六、如何判断你的应用用的是哪种代理

在生产环境中诊断性能问题时，首先要确认当前使用的代理类型。方法很简单：打印 Bean 的类名。

如果类名以 $Proxy 开头，说明是 JDK 动态代理；如果类名包含 $EnhancerBySpringCGLIB$，说明是 CGLIB 代理。

也可以通过 Arthas 等诊断工具实时监控：观察 org.springframework.aop.framework.JdkDynamicAopProxy 的 invoke 方法调用频率和耗时，就能精准定位代理层的性能瓶颈。

七、选型建议：一张表说清楚

结语

JDK 动态代理和 CGLIB 的性能差距，不是一个固定值，而是一个随场景变化的函数。在常规 Web 应用中，两者的差距不到 2%，与其纠结选哪个，不如把精力放在通知代码本身的优化上——毕竟，AOP 框架带来的开销是固定的，而你写在 @Before 里的那段数据库查询，才是真正的性能黑洞。

但在高频交易、实时计算等对延迟极度敏感的系统中，这 30% 到 40% 的差距就是生与死的距离。

别再相信"可以忽略不计"这种话了。数据不会说谎，场景决定一切。