——源码级揭秘「性能认知反转」的真相
一句话结论先行：
“JDK 动态代理更快”这条结论，在 Spring Boot 3.x / Spring Framework 6.x 时代，已经彻底失效。
很多教材、博客、面试题还停留在：
- 接口 → JDK Proxy（快）
- 没接口 → CGLIB（慢）
但现实是：
Spring Boot 3.x 在绝大多数场景下，已经「更偏向 CGLIB」，甚至在性能、功能、兼容性上全面反超 JDK 动态代理。
为什么？源码怎么说？JVM 层发生了什么变化？
本文一次讲透。
一、先把“老认知”埋了：JDK Proxy 为什么曾经快？
1️⃣ 教科书时代的结论
早期（JDK 6 / 7 + Spring 4）：
| 方案 | 原理 | 性能瓶颈 |
|---|---|---|
| JDK 动态代理 | InvocationHandler + 反射 | 反射调用慢 |
| CGLIB | ASM 生成子类 | 生成字节码 + 方法拦截 |
当年反射 = 慢，ASM = 重型武器
👉 所以结论是：JDK Proxy 更轻量
2️⃣ 但 JVM 已经不是当年的 JVM 了
从JDK 8 → JDK 17（Spring Boot 3.x 强制），发生了 3 件“地震级变化”：
- 反射已被 JIT 深度优化
Method.invoke()被内联- CGLIB 早已不是“外部库”，而是 Spring 深度定制版
👉 老结论，基础已经不存在了。
二、Spring Boot 3.x 的真实选择：源码说话
1️⃣ 默认策略在哪里？
// org.springframework.aop.framework.DefaultAopProxyFactory@OverridepublicAopProxycreateAopProxy(AdvisedSupportconfig){if(config.isOptimize()||config.isProxyTargetClass()||hasNoUserSuppliedProxyInterfaces(config)){returnnewObjenesisCglibAopProxy(config);}returnnewJdkDynamicAopProxy(config);}2️⃣ 这段代码透露了什么？
触发CGLIB的条件：
proxyTargetClass = true（Spring Boot 默认）- 没有接口
optimize = true
而Spring Boot 3.x 默认配置：
spring.aop.proxy-target-class=true📌默认强制 CGLIB，不是“退而求其次”，而是主动选择。
三、CGLIB 真的更快了吗？性能反转的底层原因
1️⃣ 调用路径对比（关键）
JDK 动态代理调用链
method() → InvocationHandler.invoke() → Method.invoke()CGLIB 调用链
method() → FastClass.invoke() → 目标方法（直接索引）2️⃣ CGLIB 的 FastClass 是什么黑科技？
CGLIB 会生成一个类似这样的类：
classUserService$$FastClass{Objectinvoke(intindex,Objecttarget,Object[]args){switch(index){case0:return((UserService)target).getUser();case1:return((UserService)target).saveUser();}}}🚀没有反射，没有 Method 对象，直接 switch + 虚调用
👉JIT 极易内联
3️⃣ JVM 层面真实情况（JDK 17）
| 项目 | JDK Proxy | CGLIB |
|---|---|---|
| 反射调用 | 虽有优化，但仍有 Method 边界 | ❌ |
| 内联能力 | ⚠️ 受限 | ✅ |
| 分支预测 | ❌ | ✅ |
| JIT 优化空间 | 中 | 高 |
📌在高频调用（AOP、事务、RPC）场景下，CGLIB 已经稳定胜出
四、Spring 为什么「不得不用」CGLIB？
1️⃣ 功能层面：JDK Proxy 的天生缺陷
| 能力 | JDK Proxy | CGLIB |
|---|---|---|
| 代理类 | ❌ 只能接口 | ✅ 任意类 |
| protected 方法 | ❌ | ✅ |
| package-private | ❌ | ✅ |
| Kotlin data class | ❌ | ✅ |
| Record / sealed | ❌ | ⚠️ 部分支持 |
👉现代 Java 应用，接口并不是标配
2️⃣ Kotlin / Record / Lombok 时代
@ServiceclassOrderService{funcreate(){}}没有接口。
JDK Proxy直接出局。
五、Spring 6 对 CGLIB 做了什么“作弊级优化”？
1️⃣ Objenesis：绕过构造函数
newObjenesisCglibAopProxy(config)- 不调用构造器
- 不污染对象状态
- 启动速度大幅提升
2️⃣ 类缓存 + ClassLoader 隔离
Enhancer.setUseCache(true);- 相同代理类只生成一次
- 大幅减少 Metaspace 压力
3️⃣ ByteBuddy / ASM 深度定制
Spring 不再用“原生 CGLIB”，而是定制版代码生成器。
👉这是框架级优化，不是你自己能写出来的那种。
六、真实压测对比（结论级）
JDK 17 + Spring Boot 3.x
单方法百万级调用
| 场景 | JDK Proxy | CGLIB |
|---|---|---|
| 单次调用 | 接近 | 接近 |
| 高频调用 | ❌ 抖动 | ✅ 稳定 |
| AOP 链较深 | ❌ 明显劣化 | ✅ |
| GC 压力 | 高 | 低 |
📌“JDK Proxy 快”只存在于「空方法 + 低频」的实验室条件
七、什么时候你还应该用 JDK 动态代理？
不是说 JDK Proxy 完全没用了。
✅ 适合 JDK Proxy 的场景
- 你明确只做代理接口
- AOP 非核心路径
- 极端追求代理对象体积最小
- 框架级代码（如 SPI）
否则：
业务系统，默认 CGLIB 是更优解
八、终极结论：这是一次「技术认知代际更替」
❌「JDK 动态代理一定更快」
❌「CGLIB 是兜底方案」
👉这些结论已经过期
✅ 新时代结论（Spring Boot 3.x）
- CGLIB 是默认、主流、最优解
- 性能已反超 JDK Proxy
- 功能完胜
- JVM 与框架共同演进的结果
九、送你一句 CSDN 爆款总结语
“不是 CGLIB 变快了，而是 JVM + Spring 终于不再为旧时代妥协。”
