这不是反射本身慢，而是JVM为优化性能在第16次调用时自动生成GeneratedMethodAccessor等动态类并加载至元空间，若卸载不及时则持续堆积导致OOM；需用jstat、jcmd、jmap和Arthas交叉验证是否真由反射膨胀引起，定位高频业务点后，禁用膨胀（-Dsun.reflect.noInflation=true）或改用MethodHandle/编译期生成根治。
直接说结论：这不是反射本身慢，而是 JVM 为优化反射性能，在第 16 次调用时自动生成 GeneratedMethodAccessor 这类动态类——它们被加载进元空间，不卸载、不复用、越积越多，最终撑爆内存。
先确认是不是真由反射膨胀引起
不能一出 Metaspace OOM 就怪反射。得用工具交叉验证：
-
jstat -gc <pid> 看
MU（已用）持续涨、MGCC（Metaspace GC 次数）长期为 0 或极低 → 元空间几乎没回收 -
jcmd <pid> VM.native_memory summary scale=MB 查
metaspace总占用，并加detail看class类型占比是否超 60% → 高度提示动态类堆积 -
jmap -clstats <pid> 统计类加载器：若出现数百上千个
sun.reflect.DelegatingClassLoader实例（每个只加载 1–2 个类），基本坐实反射膨胀 - 临时加
-XX:+TraceClassLoading -XX:+TraceClassUnloading（仅限测试环境），日志里高频刷出sun.reflect.GeneratedMethodAccessor\d+就是铁证
定位业务中谁在高频触发膨胀
膨胀不是随机发生的，它有明确触发条件：默认前 15 次走 JNI 慢路径，第 16 次起生成加速类。所以“高频”=“反复达到阈值”：
- 压测时加
-Dsun.reflect.inflationThreshold=1，如果元空间暴涨速度明显加快 → 反射就是主因 - 重点查这些场景：JSON 反序列化（Fastjson/Jackson 的 getter/setter 访问）、ORM 字段赋值（MyBatis ResultSet 映射）、通用 Bean 工具（BeanUtils.copyProperties 在循环里调用）、AOP 中绕过代理直接反射调目标方法
- 用 Arthas
watch java.lang.reflect.Method.invoke '{params, throwExp}' -n 5，看哪些业务方法的调用栈里反复出现反射入口
根治比扩容更关键
调大 -XX:MaxMetaspaceSize 只是掩盖问题。真正有效的解法是切断膨胀源头：
-
禁用膨胀机制：加 JVM 参数
-Dsun.reflect.noInflation=true→ 所有反射调用统一走动态生成路径，不再触发“第 16 次生成新类”的逻辑，彻底杜绝GeneratedMethodAccessor泛滥 -
替换反射调用：对稳定结构字段访问，优先用
MethodHandle（可缓存、无权限校验开销）、VarHandle（JDK9+，零反射开销），或编译期生成（MapStruct、Lombok） -
缓存 Method 对象：避免每次调用都
getDeclaredMethod，只解析一次，后续复用；配合setAccessible(true)跳过安全检查（确保类加载器可信）
本质上，这是 JVM 用空间换时间的一次妥协，而线上服务需要的是确定性——禁用膨胀 + 替换高频路径，比等 GC 回收更可靠。
