CGLIB与JDK代理性能对比详解

CGLIB与JDK动态代理看似都能实现AOP，实则底层机制、适用边界和隐性代价截然不同：CGLIB依赖ASM生成目标类的非final子类，虽调用性能更优但受限于final类/方法、启动慢、内存开销大且会破坏对象身份语义；JDK代理仅面向接口、零继承约束、内存友好、启动快，却需反射调用带来轻微运行时损耗。真正关键的选型依据不是“哪个更强”，而是目标类是否有接口、是否存在final方法、代理创建频率多高——选错不仅引发IllegalArgumentException、Metaspace OOM或静默拦截失效，更可能在日志、事务、序列化等环节埋下深夜告警的隐患。

选 CGLIB 还是 JDK 动态代理，不能只看“能用就行”，得看目标类有没有接口、方法是不是 final、调用频次高不高——这三点直接决定你上线后会不会踩内存暴涨、启动卡顿或 IllegalArgumentException: Cannot subclass final class 的坑。

为什么 CGLIB 必须生成子类，而 JDK 代理只能走接口

CGLIB 的核心是 Enhancer，它用 ASM 直接操作字节码，在运行时动态生成一个继承自目标类的新类（比如 UserService$$EnhancerByCGLIB$$a1b2c3d4），再重写所有非 final 方法，插入拦截逻辑。这就意味着：

• 目标类不能是 final，否则 ASM 无法继承 —— 否则抛 IllegalArgumentException: Cannot subclass final class
• 目标类的构造函数会被调用两次：一次是原始实例，一次是代理子类实例（除非显式禁用）
• 所有被代理的方法必须是非 static、非 private、非 final；final 方法会直接跳过拦截，静默失效
• JDK 代理则完全绕开继承，靠 Proxy.newProxyInstance() 生成一个实现相同接口的全新类（如 $Proxy0），所以它根本不关心目标类长什么样，只认 Class.getInterfaces() 返回的东西

JDK 代理的反射开销 vs CGLIB 的生成延迟

两者性能不能笼统说“谁快谁慢”，要看阶段：

• 类生成阶段：Proxy.newProxyInstance() 几乎瞬时完成；Enhancer.create() 要解析字节码、生成子类、加载类，首次耗时可能高出 5–10 倍（尤其类大、方法多时）
• 方法调用阶段：JDK 代理每次调用都走 Method.invoke()，有反射开销；CGLIB 代理是普通 invokevirtual 调用，实测在 JDK 8+ 上单次调用快 15%–30%
• 内存占用：CGLIB 每个代理类都新增一个 Class 对象，容易触发 Metaspace OOM（尤其高频创建代理的场景，如每个 HTTP 请求都 new 一个代理）；JDK 代理共享同一个 $ProxyX 类，内存更友好

Spring 默认切换策略背后的取舍

Spring AOP 默认启用 proxy-target-class=false（即优先 JDK 代理），不是因为 CGLIB 不好，而是为了规避两类硬限制：

• 只要目标对象实现了至少一个接口，就用 JDK 代理 —— 安全、轻量、无侵入
• 只有当目标类没接口、又没标 @EnableAspectJAutoProxy(proxyTargetClass = true)，才 fallback 到 CGLIB
• 如果你手动配了 proxyTargetClass = true，但目标类里有 final 方法，Spring 不会报错，但那些方法压根不会被切面拦截 —— 日志、事务、监控全失效，且毫无提示

真正容易被忽略的是：CGLIB 的子类机制让「对象身份语义」变了。比如 proxy instanceof UserService 为 true，但 proxy.getClass() == UserService.class 一定为 false；如果代码里用了 getClass().getSimpleName() 做路由或序列化，可能突然出错。这不是性能问题，是契约断裂。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《CGLIB与JDK代理性能对比详解》文章吧，也可关注golang学习网公众号了解相关技术文章。