Metaspace OOM本质是类元数据总量超限且GC无法卸载无用类，典型场景包括动态生成大量类（CGLib/MyBatis/Groovy/Spring AOP）、类加载器未回收、JSP/模板引擎高频编译、参数设置不合理及反射代理滥用。
永久代（PermGen）在 Java 7 及以前版本中用于存储类元数据，Java 8 起被元空间（Metaspace）取代。两者功能相似，但元空间直接使用本地内存（Native Memory），不再受 JVM 堆大小限制，因此溢出表现和成因略有差异。Metaspace OOM 的本质是：JVM 加载的类元数据总量超过了元空间可用容量，且 GC 无法卸载无用类释放空间。
动态生成大量类
这是最典型的触发场景。框架如 CGLib（代理增强）、MyBatis（Mapper 接口动态生成代理类）、Groovy（运行时编译脚本）、Spring AOP（生成大量代理类）等，在运行期频繁生成新类。每个类的结构信息（方法签名、字段、常量池等）都占用元空间，若类数量持续增长且不卸载，就会快速耗尽空间。
类加载器未正确回收
当应用频繁部署/热更新（如 Tomcat 中反复 reload 应用）、使用自定义 ClassLoader 加载类但未显式释放、或第三方库存在类加载器泄漏时，已加载的类无法被 GC 卸载——因为类对象与其 ClassLoader 强关联，ClassLoader 持有引用则整个类簇无法回收。这类泄漏会累积大量“僵尸类”，最终撑爆元空间。
JSP 编译与模板引擎高频使用
传统 Web 容器（如旧版 Tomcat）将每个 JSP 页面编译为独立 Servlet 类，每次修改 JSP 都可能生成新类；类似地，Thymeleaf、Freemarker 等模板引擎若开启调试模式或动态重编译，也会持续注册新类。若未配置合理的类卸载策略或缓存机制，元空间压力会显著上升。
元空间参数设置不合理
默认情况下，元空间大小无硬上限（仅受本地内存限制），容易掩盖问题；而人为设置 -XX:MaxMetaspaceSize 过小（如仅 64M），又可能在正常业务规模下就触发 OOM。尤其在微服务多模块、插件化架构或含大量第三方 SDK 的项目中，初始预估不足会导致频繁溢出。
反射与动态代理滥用
大量使用 java.lang.reflect.Proxy 或 MethodHandle、频繁调用 Class.forName() 加载类、或通过 Unsafe.allocateInstance 绕过构造器创建实例等操作，都会间接增加类加载频率和元数据驻留时间。若缺乏复用机制（如缓存 Proxy 类），易造成冗余类堆积。
