反射卡顿主因是元空间膨胀引发full gc，非栈区存根类；存根类由delegatingclassloader加载至元空间，卸载条件苛刻导致累积oom；禁用膨胀（-dsun.reflect.noinflation=true）和改用methodhandle可根治。
反射调用高频膨胀导致的卡顿，根本不是“栈区产生存根类”——这个说法本身存在概念错误。存根类（如 GeneratedMethodAccessor）是动态生成的 Java 类，由 sun.reflect.DelegatingClassLoader 加载，存储在 元空间（Metaspace），而非栈区。栈区只存放局部变量、方法调用帧和少量引用，不承载类定义。所谓“卡顿”，实为元空间持续增长 → 触发频繁 Full GC 或直接 OOM → 应用停顿，表象是响应延迟、吞吐骤降。
先确认是不是真由反射膨胀引发卡顿
别凭感觉，靠三步证据链交叉验证：
-
看元空间水位与回收行为：执行
jstat -gc <pid></pid>，若MU（已用元空间）持续爬升、MC（容量）逼近MX（最大值），且MGCC（元空间 GC 次数）长期为 0 或极低，说明类几乎不卸载 -
查类加载器分布：运行
jmap -clstats <pid></pid>，重点找sun.reflect.DelegatingClassLoader实例数。若出现数百甚至上千个，每个只加载 1–2 个类（如GeneratedMethodAccessor47），基本坐实反射膨胀 -
抓类加载日志（压测时启用）：加 JVM 参数
-XX:+TraceClassLoading -XX:+TraceClassUnloading，观察是否高频刷出sun.reflect.GeneratedMethodAccessor\d+或DelegatingConstructorAccessorImpl
为什么这些类“卸载不掉”，最终拖垮系统
关键不在“生成”，而在“卸载条件太苛刻”：
-
DelegatingClassLoader是匿名类加载器，无强引用链，但卸载需同时满足：该加载器自身不可达、它加载的所有类无活动实例、无静态字段引用、无 JNI 全局引用 —— 实际业务中极易卡在任一环节 - 一个 setter 方法被 100 个不同 Bean 反射调用，可能生成 100 个独立的
GeneratedMethodAccessor类（类名带序号，无法复用） - 每个类虽仅几 KB，但累积数千个后轻松突破默认 256MB 元空间，触发 Full GC；而元空间 GC 本身开销大、STW 时间长，用户感知就是明显卡顿
定位具体哪段代码在高频触发膨胀
膨胀有明确阈值（默认第 16 次调用触发），所以高频 = 高危：
-
临时降低阈值验证：启动时加
-Dsun.reflect.inflationThreshold=1，再压测。若卡顿加剧、元空间暴涨加速，即可锁定反射为根因 -
扫描高危场景：JSON 反序列化（Jackson/Fastjson 的 getter/setter）、ORM 字段赋值（MyBatis ResultSet 映射）、Bean 工具（
BeanUtils.copyProperties）、AOP 中绕过代理直接反射调用目标方法 -
用 Arthas 快速抓热点：执行
watch java.lang.reflect.Method invoke '{params,returnObj}' -n 5，结合stack查看调用栈，直击业务层反射入口
根治方案：禁用膨胀 + 替换调用路径
扩容 -XX:MaxMetaspaceSize 只是拖延，必须切断源头：
-
强制禁用膨胀机制：加 JVM 参数
-Dsun.reflect.noInflation=true。此后所有反射统一走动态生成路径，不再分“前15次/第16次”，彻底杜绝GeneratedMethodAccessor批量生成 -
对高频字段/方法访问，改用 MethodHandle：支持预编译、可复用、不触发类生成，性能接近直接调用；比缓存
Method对象更进一步 -
框架层规避：Jackson 配置
DeserializationFeature.USE_JAVA_ARRAY_FOR_JSON_ARRAY减少反射；MyBatis 开启useColumnLabel=false降低ResultSet字段匹配开销
