记录一次 反射引起的Metaspace OOM 的完整排查
一、问题背景
线上某个 Spring Boot 服务偶发出现：
java.lang.OutOfMemoryError: MetaspaceJVM 参数中已经限制：
-XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m但监控显示：
Metaspace used ≈ 370MB Metaspace committed ≈ 508MB看起来仍然有约100MB+ 空间，却仍然发生 OOM，因此开始排查。
二、GC 日志分析
OOM 前 GC 日志关键片段：
GC cause: Metadata GC Threshold Full GC (Metadata GC Threshold) Metaspace: 357743K -> 357743K随后出现：
Full GC (Last ditch collection)几个关键点：
- GC 触发原因是Metadata GC Threshold
- Full GC 后 Metaspace没有下降
- 出现Last ditch collection（最后一次尝试回收）
这通常说明：
- JVM 尝试通过 Full GC 卸载类
- 但没有任何 ClassLoader 被回收
- Metaspace 无法释放
通常意味着：
- ClassLoader 泄漏
- 或动态生成大量类
三、Heap Dump 分析
导出 dump 后首先统计 ClassLoader：
ClassLoader 总数：7775其中绝大多数是：
sun.reflect.DelegatingClassLoader正常 Spring Boot 应用：
ClassLoader 通常 < 100因此这是一个明显异常信号。
四、定位动态生成的类
继续统计 dump 中的类：
sun.reflect.GeneratedMethodAccessorXXX数量：
7289这是 JDK 反射生成的MethodAccessor 优化类。
JDK8 的反射机制如下：
Method.invoke() ↓ 调用次数 > 15（InflationThreshold） ↓ JVM 生成字节码类 sun.reflect.GeneratedMethodAccessorXXX ↓ 通过 sun.reflect.DelegatingClassLoader 加载因此关系基本是：
1 MethodAccessor class ≈ 1 DelegatingClassLoader统计结果：
GeneratedMethodAccessor ≈ 7289 DelegatingClassLoader ≈ 7765基本一致。
五、哪些类触发了反射 inflation？
在 MAT 中通过 OQL 查询：
SELECT this['clazz']['name'], count(1) FROM "java.lang.reflect.Method" WHERE this['methodAccessor'] != null GROUP BY this['clazz']['name']统计结果（已脱敏）：
XXX.dto.XXXDto 1625 XXX.dto.XXXDetailDto 1332 XXX.dto.XXXDocumentDto 871 XXX.common.dto.XXXBaseDto 807 XXX.xxxx.dto.XXXXXXXDto 731 XXX.transport.XXXBaseDto 699 XXX.domain.entity.XXXEntity 692 XXX.domain.entity.XXXDocument 502 XXX.dto.XXXParamDto 488 org.apache.ibatis.XXX 416 XXX.dto.XXXTemplateDto 402可以看到几个明显特征：
- 大部分都是DTO / Entity
- 同时出现MyBatis 相关类
- getter / setter 方法被大量反射调用
这与 ORM 框架的工作模式一致。
六、为什么 900+ 个类会产生 7000+ ClassLoader？
统计结果：
触发 inflation 的类 ≈ 961 GeneratedMethodAccessor ≈ 7289原因是：
一个 DTO / Entity 往往包含很多 getter / setter，例如：
UserDto getId() setId() getName() setName() getCreateTime() setCreateTime()一个类通常有：
10 ~ 20 个 getter/setter只要某个方法：
Method.invoke() 调用次数 > 15JVM 就会生成：
GeneratedMethodAccessor因此：
961 类 × 平均 7~8 个方法 ≈ 7000 accessor与实际统计：
7289基本一致。
七、系统到底加载了多少类？
进一步统计所有 ClassLoader：
EXPR$0 | EXPR$1 ----------------------------------------------------------------------------- org.springframework.boot.loader.LaunchedURLClassLoader | 44414 <system class loader> | 5245 sun.misc.Launcher$ExtClassLoader | 176 sun.misc.Launcher$AppClassLoader | 53加上反射生成类后：
系统总加载 class ≈ 58414 ClassLoader 数量 ≈ 7775八、Metaspace 实际占用计算
监控数据：
Metaspace used ≈ 370MB Metaspace committed ≈ 508MB计算平均每个 class metadata 占用：
370MB / 58414 ≈ 6.5KB也就是说：
平均每个 class metadata ≈ 6.5KB这个数值完全符合 HotSpot 的典型范围：
4KB ~ 12KB / class说明：
Metaspace 的主要占用其实是应用自身加载的 class。
九、反射类在其中占多少？
动态生成类：
GeneratedMethodAccessor ≈ 7289这类 class 结构非常简单，metadata 体积通常：
2KB ~ 4KB粗略估算：
7289 × ~3KB ≈ 20MB因此 Metaspace used 的大致结构：
应用 class metadata ≈ 340MB GeneratedMethodAccessor ≈ 20MB 其它 reflection metadata ≈ 10MB -------------------------------- Metaspace used ≈ 370MB十、为什么 used 370MB 仍然 OOM？
关键原因是：
Metaspace used ≠ 可继续分配的空间Metaspace 由ClassLoader arena + chunk管理。
特点：
- 每个 ClassLoader 有自己的 arena
- arena 内存按chunk分配
- chunk不会在 ClassLoader 之间共享
当系统接近上限：
MaxMetaspaceSize = 512MB Metaspace committed ≈ 508MB如果 JVM 需要加载新的 class（例如新的 accessor）：
需要申请新的 metaspace chunk。
但此时：
508MB + 新 chunk > 512MB扩容失败。
于是 JVM 触发：
Metadata GC Threshold → Full GC → Last ditch collection → OOM十一、问题本质
问题链路如下：
DTO / Entity getter/setter ↓ MyBatis / ORM 反射调用 ↓ Method.invoke() ↓ JDK8 reflection inflation ↓ GeneratedMethodAccessor ↓ DelegatingClassLoader ↓ Metaspace 持续增长 ↓ 无法扩容 ↓ Metaspace OOM十二、解决方案
最直接方案：
关闭 reflection inflation：
-XX:-UseInflation效果：
- 不再生成 GeneratedMethodAccessor
- 不再创建 DelegatingClassLoader
- metaspace 使用量显著下降
线上经验：
Metaspace 500MB → 100MB 左右性能影响：
通常< 3%。
另一种方案：
提高阈值：
-XX:InflationThreshold=1000默认值：
15只有极高频 Method 才会生成 accessor。
十三、为什么 JDK11 不会有这个问题？
JDK11 开始逐步使用MethodHandle替代 reflection inflation。
JDK8：
Method.invoke → GeneratedMethodAccessor（生成 class）JDK11：
Method.invoke → MethodHandle → JVM 内联优化不再生成 accessor class，也不会产生 DelegatingClassLoader。
因此 Metaspace 会明显更稳定。
十四、最终 JVM 参数
生产环境最终配置：
-XX:-UseInflation -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=768m上线后：
GeneratedMethodAccessor = 0 Metaspace 使用稳定在 ≈ 120MB总结
这次问题的核心链路是：
DTO / ORM 框架反射调用 → Method.invoke → JDK8 reflection inflation → GeneratedMethodAccessor → DelegatingClassLoader → Metaspace 膨胀 → OOM关键经验：
- Metaspace OOM 不一定是类加载过多，也可能是 reflection inflation。
GeneratedMethodAccessor数量可以快速判断问题。- JDK8 可以通过
-XX:-UseInflation直接规避。 - JDK11 之后该问题基本消失。
- Metaspace used 并不等于可继续分配空间。
在使用大量 DTO、ORM、RPC 框架的系统中，如果看到：
GeneratedMethodAccessor DelegatingClassLoader Metadata GC Threshold基本可以优先考虑reflection inflation 导致的 Metaspace 问题。 :::