反射调用会触发JVM生成GeneratedMethodAccessor等动态类并加载至元空间，高频调用且卸载不及时将导致元空间OOM；需通过jstat、jcmd、jmap及Arthas定位反射热点，禁用膨胀或改用MethodHandle根治。
反射调用本身不直接“生成变量”，但会触发 JVM 内部动态生成加速类（如 GeneratedMethodAccessor），这些类被加载进元空间（Metaspace）。当调用量大、卸载不及时，就会堆积导致元空间持续增长甚至 OOM。排查关键不是看“变量”，而是定位高频反射点、确认膨胀类生成行为、验证类卸载是否失效。
确认元空间压力是否真由反射引起
先排除误判，避免把 CGLIB 代理、Groovy 脚本或热部署问题当成反射问题：
- 运行
jstat -gc，重点关注 MU（Metaspace used）是否持续上涨、MC（Metaspace capacity）是否逼近 MX（MaxMetaspaceSize），且 MGCC（Metaspace GC 次数）长期为 0 或极低——说明元空间几乎没被回收 - 执行
jcmd，查看 metaspace 区总占用，并追加VM.native_memory summary scale=MB detail看 class 类型占比是否异常高（>60%） - 临时加参数
-XX:+TraceClassLoading -XX:+TraceClassUnloading（生产慎用），观察日志中是否高频出现sun.reflect.GeneratedMethodAccessor\d+或DelegatingConstructorAccessorImpl类名 - 用
jmap -clstats查类加载器统计，若发现大量sun.reflect.DelegatingClassLoader实例（每个通常只加载 1–2 个类），且总数达数百上千，基本可锁定反射膨胀
定位具体业务反射热点
反射膨胀类的生成有明确触发逻辑：默认前 15 次调用走慢路径（JNI），第 16 次起自动生成字节码加速器类。因此高频调用 = 高频生成：
- 临时降低阈值验证：加 JVM 参数
-Dsun.reflect.inflationThreshold=1后压测，若元空间增长速度明显加快，即可确认是反射膨胀主导 - 检查常见高危场景：JSON 反序列化（Jackson/Fastjson 的 getter/setter 访问）、ORM 字段赋值（MyBatis 的
ResultSet映射）、通用 Bean 工具（Apache BeanUtils、Spring BeanUtils.copyProperties）、AOP 中绕过代理直接反射调用目标方法 - 用 Arthas 的
trace或watch命令，监控java.lang.reflect.Method.invoke调用栈，快速定位被频繁反射调用的具体业务方法
缓解与根治策略
不能只靠调大 -XX:MaxMetaspaceSize，需从机制上减少类生成、提升卸载率：
-
禁用反射膨胀机制：加参数
-Dsun.reflect.noInflation=true。此后所有反射调用统一走动态生成路径，不再触发“膨胀”逻辑，彻底杜绝GeneratedMethodAccessor类生成。首次调用性能略降（约 1.5x），但后续稳定且无元空间压力 -
替换为 MethodHandle：对确定高频的字段/方法访问，改用
MethodHandles.lookup().findVirtual/finderSetter获取句柄并缓存复用。它支持预编译、无类生成、性能接近直接调用 -
避免在循环或高频路径中新建反射对象：如不要在 for 循环里反复
clazz.getMethod("xxx")，应提取到静态块或单例中缓存Method实例 - 确保类可卸载：检查是否有静态集合、ThreadLocal、监听器等强引用了 Class 或其 ClassLoader，否则即使不用了，类元数据也无法从元空间释放
不复杂但容易忽略：反射膨胀不是 bug，而是 JVM 的优化机制；问题出在“量大+卸载失败”的组合。找准调用点、关掉膨胀、换更稳的替代方案，元空间压力自然回落。
