如何排查Java内存溢出OOM并监测元空间变量异常增长实战-java教程-PHP中文网

元空间异常增长是Java OOM关键突破口，需通过jstat、jcmd检查MC/MU/CCSU及loadedClassCount变化，结合NMT定位类加载器泄漏或动态类生成问题，并通过限值、启用卸载、修复ClassLoader等治本。

如何排查java内存溢出oom并监测元空间变量异常增长实战

Java内存溢出（OOM）排查不能只盯着堆，尤其当堆使用率正常但进程RSS持续飙升、服务莫名重启或报 java.lang.OutOfMemoryError: Metaspace 时，元空间异常增长就是关键突破口。

不等OOM发生，先看实时指标：

执行 jstat -gc ，关注输出中 MC（Metaspace容量）、MU（已用Metaspace）是否随时间单向上涨，且 CCSU（压缩类空间已用）同步上升
执行 jcmd VM.classloader_stats，检查 loadedClassCount 是否持续增加，unloadedClassCount 增长缓慢甚至为0 —— 这说明类卸载失败，极可能是类加载器泄漏
对比两次 jstat -class 2s 输出，若 Loaded 值净增而 Unloaded 几乎不动，基本可锁定元空间泄漏

元空间本身不存对象实例，它膨胀一定是因为“类”或“类加载器”在堆积。重点查两类：

java-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

动态类生成场景：Spring Boot + CGLIB代理、MyBatis Mapper动态代理、Groovy脚本、JSP编译、热部署（DevTools）、字节码增强（如SkyWalking、Arthas插件）——这些都会高频生成新类，且部分类加载器无法被回收
类加载器泄漏：Web应用中，一次热部署/模块重载后旧ClassLoader未被GC，它加载的所有类元数据仍驻留元空间；常见于自定义ClassLoader未正确实现 findClass 或未释放对上下文（如ThreadLocal、静态引用）的持有

仅靠jstat不够细，开启Native Memory Tracking（NMT）才能看清元空间到底被谁吃掉：

重启JVM时加上：-XX:+UnlockDiagnosticVMOptions -XX:NativeMemoryTracking=summary（上线环境建议用 summary，避免 detail 开销过大）
运行中执行：jcmd VM.native_memory summary
重点关注输出中 Metaspace / Class 项的 committed 和 used 值，若该值持续增长，再配合 jcmd VM.classloader_stats 查加载器数量是否同步增加

确认问题后，不要只调大参数，要治本：

加启动参数限制上限：-XX:MaxMetaspaceSize=256m（根据应用类数量合理设，256m~512m起步，避免无界增长拖垮宿主机）
启用类卸载：-XX:+ClassUnloadingWithConcurrentMark（G1默认开启，CMS需显式加；配合-XX:+UseConcMarkSweepGC更稳妥）
检查代码中所有自定义ClassLoader，确保其 loadClass 不持有外部强引用，且在不用时主动置null或调用 close()
禁用非必要动态特性：如关闭Spring DevTools热部署、限制MyBatis Mapper代理深度、避免在循环中用Class.forName反复加载同一类

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南