Java 8后方法区被元空间取代，使用本地内存存储类元数据；动态类加载频繁、字节码膨胀及类卸载失败易导致Metaspace OOM；需通过启用类卸载、监控类加载趋势、限制动态行为等手段根治。
方法区在 Java 8 之后被元空间（Metaspace）取代，它不再位于堆内存中，而是使用本地内存（Native Memory）存储类的元数据：类名、字段、方法签名、注解、常量池等。一旦动态类加载频繁或类元数据持续增长且无法卸载，元空间就容易耗尽，抛出 java.lang.OutOfMemoryError: Metaspace。
动态类加载是元空间膨胀的主因
不是所有类加载都会引发问题，但以下场景会显著增加元空间压力：
- CGLIB 或 Javassist 等字节码生成库频繁创建代理类（如 Spring AOP 默认使用 CGLIB），尤其当
setUseCache(false)被显式调用时，每次调用都生成全新类 - 反射大量调用
Class.forName()或defineClass()，尤其配合自定义类加载器未释放时 - 热部署环境（如 Tomcat 重启、Spring Boot DevTools）反复加载/卸载应用，旧 ClassLoader 残留导致其加载的类元数据无法回收
- Groovy/JSR-223 脚本引擎在运行时编译脚本为类，且未做缓存或清理
字节码膨胀加剧元空间占用
单个类的元数据大小并非固定，受字节码结构影响明显：
- 方法数量多、签名复杂（泛型嵌套深、参数类型多）、异常表庞大，都会推高单个类的元数据体积
- 大量使用 Lambda 表达式或匿名内部类，JVM 会为每个实例生成独立的类文件，类数量线性增长
- 第三方库自带大量注解（如 Lombok 编译期生成、Hibernate Validator 的约束注解），部分注解保留在运行时并计入元空间
- 调试信息（
-g编译选项）保留行号、局部变量表，也会小幅增加元数据开销
识别与遏制元空间溢出的关键动作
不能只靠增大 -XX:MaxMetaspaceSize 来掩盖问题，需定位根源并收敛增长：
- 启动时强制启用类卸载：
-XX:+UseConcMarkSweepGC -XX:+CMSClassUnloadingEnabled（CMS）或-XX:+UseG1GC -XX:+ClassUnloadingWithConcurrentMark（G1） - 监控类加载趋势：用
jstat -gc <pid>查看MU（Metaspace Used）和MC（Metaspace Capacity），持续上升且不回落是泄漏信号 - 触发类卸载分析：执行
jcmd <pid> VM.class_hierarchy -all或jcmd <pid> VM.native_memory summary辅助判断类加载器存活状态 - 限制非必要动态行为：关闭 DevTools 热部署、禁用 Groovy 脚本执行、CGLIB 代理开启缓存（
setUseCache(true)）
