jdk代理因强制参数装箱和反射调用导致更高gc压力与内存分配率，cglib通过methodproxy绕过反射、更易被jit内联，整体性能更优。
Java动态代理的性能压测中，JDK代理与CGLIB代理在变量处理上的差异，并不体现在“变量本身”的读写开销上，而是反映在方法调用链中对参数、返回值、异常等对象的传递与封装方式，以及代理层对这些对象的访问路径是否引入额外开销。所谓“变量处理”，实际是代理机制在拦截方法调用时，如何承载和流转入参（Object[] args）、目标实例（target）、返回值及异常——这些环节直接影响高频调用下的吞吐与延迟。
参数数组封装：JDK代理有明确反射开销
JDK动态代理要求所有方法调用必须通过InvocationHandler.invoke(Object proxy, Method method, Object[] args)统一入口。这意味着：
- 每次调用都会将原始参数强制装箱为
Object[]数组（即使只有1个基本类型参数，也要自动装箱+新建数组） -
method.invoke(target, args)再次触发Java反射调用，涉及安全检查、参数类型匹配、访问权限校验等运行时操作 - 若方法含
final或private字段访问需求，无法绕过反射——而变量本身无特殊处理，但访问路径被拉长
方法拦截方式：CGLIB避免反射，但引入字节码跳转
CGLIB使用MethodInterceptor.intercept(Object obj, Method method, Object[] args, MethodProxy proxy)，关键区别在于：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
MethodProxy预先缓存了父类方法的FastClass索引，调用proxy.invokeSuper(obj, args)时直接跳转到目标方法字节码，绕过Method.invoke() - 参数仍以
Object[] args形式传入，但无需重复反射解析；基本类型参数仍需装箱，这点与JDK一致 - 由于生成的是子类，对目标类中非
final实例变量的直接访问（如this.field）不受影响，代理层不干预变量读写逻辑
局部变量与闭包行为：两者均无代理介入
代理机制只作用于方法调用边界，不影响方法体内的局部变量声明、赋值或作用域。例如：
- 目标方法中定义的
int x = 5;、String s = "hello";完全在JVM栈帧内执行，代理不感知也不干预 -
InvocationHandler或MethodInterceptor内部使用的局部变量，属于代理逻辑自身，与被代理方法无关 - Lambda或匿名内部类形成的闭包变量，其捕获逻辑由编译器决定，代理不改变其生命周期或访问方式
真实压测中值得关注的变量相关指标
单纯比“变量处理速度”没有意义，但以下与变量间接相关的指标在压测中常暴露差异：
-
GC压力：JDK代理因频繁创建
Object[]参数数组，在高QPS下易引发年轻代GC；CGLIB虽也传Object[]，但整体调用路径更短，GC频率略低 - 内存分配率（Allocation Rate）：可通过JFR或JMC观测每秒新分配的数组对象数，JDK代理通常高出10%–30%
-
热点方法内联失败率：JDK代理的
invoke因反射调用难以被JIT内联，导致方法调用栈更深，局部变量访问的寄存器优化可能受限；CGLIB的intercept更易被内联，有利于JVM优化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
