排查反射调用导致的字节码膨胀，核心是确认是否批量生成GeneratedMethodAccessor类并定位触发点，通过jstat、jmap、jcmd及日志追踪验证，结合调整inflationThreshold参数和Arthas定位高危代码，最终通过禁用膨胀、改用MethodHandle/VarHandle或启用类卸载来根治。
排查反射调用因突破 -Dsun.reflect.inflationThreshold 触发的字节码膨胀，核心是确认“是否真在生成 GeneratedMethodAccessor 类”，并锁定具体触发点。这不是看调用慢不慢，而是查类有没有批量出生、能不能被回收。
确认元空间里是不是真堆满了膨胀类
先别猜，用工具说话：
- jstat -gc <pid>：重点看 MU（Metaspace used） 是否单边上涨、MGCC（Metaspace GC 次数） 长期为 0 或极低——说明类几乎不卸载
- jmap -clstats <pid>：搜 sun.reflect.DelegatingClassLoader，若实例数达数百上千，且每个只加载 1–2 个类，基本就是它在批量产子
- jcmd <pid> VM.native_memory summary scale=MB：追加 detail 查 class 类型占比，若 >60%，再结合上面两项，可信度极高
- （测试环境可用）加参数 -XX:+TraceClassLoading -XX:+TraceClassUnloading 启动，压测时盯日志：高频刷出 sun.reflect.GeneratedMethodAccessor\d+ 或 DelegatingConstructorAccessorImpl 就是铁证
验证是不是 inflationThreshold 在起作用
阈值不是摆设，它是开关。动手调一调，看反应：
- 临时加 -Dsun.reflect.inflationThreshold=1 再压测，如果 Metaspace 增速明显加快、jmap -clstats 里 DelegatingClassLoader 数量暴增，说明业务反射确实高频，且当前阈值正在被反复击穿
- 反过来，若把阈值设得极大（比如 2147483647），Metaspace 增长停了，但年轻代 Eden/From 占用飙升，说明你只是把压力从 Metaspace 转移到了对象分配和 GC 上——JNI 路径变慢，导致更多临时对象堆积
定位具体哪段代码在高频触发膨胀
GeneratedMethodAccessor 不是天上掉的，它一定对应真实业务方法：
- 常见高危场景优先排查：JSON 反序列化（Jackson/Fastjson 的 setter/getter）、MyBatis 结果集映射字段赋值、Spring/BeanUtils.copyProperties、AOP 中绕过代理直接反射调用目标方法
- 用 Arthas trace java.lang.reflect.Method.invoke，看调用栈顶层是谁；或 watch java.lang.reflect.Method.invoke '{params,returnObj}' -n 5 抓样本，快速定位被反复 invoke 的 Method 对象
- 检查是否对 private 方法频繁调用 setAccessible(true)：这会禁用膨胀机制，强制走最慢 JNI 路径，反而可能引发更多次“首次调用”行为，间接加剧类加载压力
缓解与根治的关键动作
扩容 Metaspace 是拖延，禁用膨胀或换路径才是止血：
- 加启动参数 -Dsun.reflect.noInflation=true：所有反射统一走动态生成路径，跳过“前N次JNI→第N+1次生成”的逻辑，彻底杜绝 GeneratedMethodAccessor 批量诞生
- 对确定高频的字段/方法访问，逐步替换为 MethodHandle（可复用、支持预绑定）或 VarHandle（JDK9+，零开销）
- 确保 GC 支持类卸载：G1 加 -XX:+UnlockExperimentalVMOptions -XX:+ClassUnloading，CMS 加 -XX:+CMSClassUnloadingEnabled；Parallel GC 不支持，必须换
