动态代理几乎是所有主流框架的基石：Spring的AOP、MyBatis的Mapper接口、Dubbo的服务引用、Hibernate的懒加载实体，底层都依赖JDK动态代理或CGLIB字节码增强。多数开发者只关注代理对象本身在堆上的占用，却忽略了一个更隐蔽的问题：每次代理方法的调用，都会在虚拟机栈上生成一批额外的局部栈变量。当系统并发量上去之后，这些不起眼的槽位会显著放大栈内存压力，甚至触发StackOverflowError。本文将从栈帧结构出发，系统分析动态代理带来的局部变量开销，并建立一套可量化的内存开销模型。
一、先弄清楚栈帧里到底装了什么
要分析局部栈变量的开销，必须先理解JVM的栈帧（Stack Frame）结构。每个方法从调用到执行完成的过程，都对应着一个栈帧在虚拟机栈上的入栈和出栈。栈帧由三部分组成：局部变量表（Local Variable Table）、操作数栈（Operand Stack）和帧数据区（动态链接、方法返回地址等）。
局部变量表以变量槽（Slot）为最小单位，在64位HotSpot虚拟机上，每个Slot占用4字节对齐空间，long和double类型占用两个Slot。方法参数、方法体内声明的局部变量都会被编译器分配到这些Slot中。关键在于：局部变量表的大小在编译期就已经确定，写入了Code属性的max_locals字段，运行期无法改变。
举个例子，一个普通的业务方法可能只需要5个Slot，但经过动态代理包装后，实际的调用链变成了“客户端调用代理方法 → 代理方法调用InvocationHandler → Handler内部反射调用真实方法”，一次逻辑调用被展开为至少三次物理调用，每次调用都有独立的栈帧。这就是代理开销的第一个来源：栈帧数量成倍增加。
二、JDK动态代理调用链的局部变量拆解
JDK动态代理生成的类继承了java.lang.reflect.Proxy，每个被代理接口方法在生成类中都有对应实现。我们通过sun.misc.ProxyGenerator或者JDK8以后的jdk.internal.proxy.ProxyGenerator可以导出代理类的字节码。以一个简单接口方法为例，生成的代理方法大致等价于以下代码：
public final void save(User user) throws Throwable {
try {
// m3是缓存好的Method对象，作为静态字段存在
// h是继承自Proxy的InvocationHandler引用
super.h.invoke(this, m3, new Object[]{user});
} catch (Throwable e) {
throw new InvocationTargetException(e);
}
}从字节码层面看，这个代理方法内部至少引入了以下局部变量：代理对象自身引用（this）、方法参数（user）、新创建的Object数组引用、调用返回值临时变量、以及异常处理器使用的Throwable引用。相比直接调用，多出了数组对象和一系列中间引用。
更重要的开销发生在InvocationHandler.invoke内部。以Spring的DynamicAdvisedInterceptor为例，方法拦截时会创建MethodInvocation对象、读取拦截器链（一个List转数组的操作）、包装参数数组、构造反射调用的MethodAccessor。这些操作产生的引用全部作为局部变量压入当前栈帧，单个栈帧的局部变量表从普通的5到8个Slot膨胀到20个以上。
还有一个容易被忽视的点：反射调用本身。以Method.invoke为入口的调用在JDK 8之前会走Native方法，之后默认走字节码生成的GeneratedMethodAccessor。GeneratedAccessor方法会把所有参数平铺到局部变量表中，参数越多，这个栈帧越宽。曾有真实案例：一个接收大DTO作为参数的接口方法，被AOP层层包裹后，单次调用的栈深度达到直接调用的4倍，压测时频繁出现栈溢出。
三、CGLIB与JDK代理的栈开销对比
CGLIB通过生成目标类的子类来实现代理，方法拦截通过重写方法并插入拦截逻辑完成。它的调用链是“调用子类方法 → 方法拦截器intercept → 反射调用父类原方法（通过FastClass机制索引）”。与JDK代理相比，CGLIB引入了MethodProxy和两个FastClass索引参数。
public Object intercept(Object obj, Method method, Object[] args,
MethodProxy proxy) throws Throwable {
// CGLIB特有的局部变量：MethodProxy、fastClassInfo
// invokeSuper会通过索引直接定位父类方法，避免纯反射
return proxy.invokeSuper(obj, args);
}CGLIB的FastClass机制用int索引代替反射查找Method对象，理论上减少了Method相关的局部变量和查找开销。但代价是每个代理类要生成两个额外的FastClass类，增加元空间（Metaspace）压力。两者在栈上的差异总结如下表：
| 对比项 | JDK动态代理 | CGLIB |
|---|---|---|
| 栈帧层数（单次调用） | 3至4层 | 3至5层 |
| 额外局部变量来源 | Object参数数组、Method引用 | MethodProxy、FastClassInfo、方法索引 |
| 参数传递方式 | 装箱为数组，引用传递 | 原始参数平铺，部分场景避免装箱 |
| 类加载开销 | 仅代理类本身 | 代理类加两个FastClass |
| 元空间占用 | 较低 | 约为JDK代理的3倍 |
可以看到，CGLIB在栈变量数量上略有优势（参数平铺避免了数组装箱带来的额外引用），但在类数量和元空间上吃亏。Spring默认在目标类实现接口时选择JDK代理，否则退回CGLIB，这个选择本身就隐含了对两类开销的权衡。
四、建立可度量的内存开销模型
理解原理之后，我们需要一套可复用的度量方法。分析栈开销的核心思路是：用JVM参数-XX:+PrintCompilation配合字节码反编译确认max_locals，再结合线程栈转储统计真实栈深度。
第一步，导出代理类字节码。JDK 8可以设置-Dsun.misc.ProxyGenerator.saveGeneratedFiles=true，JDK 9以后使用-Djdk.proxy.ProxyGenerator.saveGeneratedFiles=true。导出后用javap -v查看每个方法的max_locals字段，这个值乘以4字节（考虑对齐）就是该栈帧局部变量表的静态大小。
# 导出代理类后反编译查看局部变量表大小 javap -v com.sun.proxy.$Proxy0.class | grep -A 2 "public abstract"
第二步，抓取运行时线程栈。通过jstack或在代码中调用Thread.currentThread().getStackTrace()，在代理调用最深处采样，统计代理链贡献的帧数。用JMH做基准测试时，可以注入一个StackProbe拦截器放在拦截器链最内层，测量满栈场景下的调用路径长度。
第三步，套用开销估算公式。假设单次代理调用的额外栈开销为S，可以近似表示为：S = Σ(每层栈帧的max_locals × 4字节) + 每层帧数据区固定开销（HotSpot上约32到64字节）。再乘以并发线程数N，就得到框架代理层带来的总栈内存增量。例如一个max_locals平均为12的拦截链、总共4层栈帧、200个并发线程，增量约为 12 × 4 × 4 × 200 ≈ 38400字节，接近4MB——这只是栈上的开销，还不算堆上每次调用创建的Object数组和方法调用上下文对象给年轻代GC带来的压力。
五、降低局部栈变量开销的实践方案
第一，控制拦截器链长度。Spring AOP中每个Advisor都会让拦截链变长一层栈帧。审查切面表达式，避免过宽的切点匹配，把校验、日志、监控等横切逻辑合并到一个拦截器中，可以线性减少栈帧数量。
第二，减少不必要的参数装箱。接口方法参数过多时，JDK代理会创建大Object数组，既占堆也占栈引用。将多个参数封装为单一请求对象，或者对热点方法提供绕过代理的直接调用路径（例如通过内建的函数式分发），都是有效手段。
第三，合理设置线程栈大小。测算出单线程最大栈深度后，用-Xss精确配置。默认1MB在深代理链加深层递归场景下并不宽裕，但盲目调大又会挤占物理内存，必须以度量数据为依据。
第四，关注元空间与堆的联动开销。CGLIB的FastClass、代理类本身、Method缓存都在元空间或堆中，建议开启-XX:+ClassUnloading并监控jvm.clazz相关指标，防止动态生成类在热部署场景下泄漏。通过以上手段，把代理层的内存开销从“黑盒猜测”变成“模型加数据”的可控工程问题，这正是框架性能调优走向精细化的必经之路。