JVM 服务半夜告警排查下来是 Metaspace 内存溢出。这个报错在 JDK 8 及以后出现的频率越来越高很多人第一反应是“不是已经把永久代换成元空间了吗怎么还会溢出”。我做过一次完整的动手实验来还原这个问题从复现、定位到解决整个过程记录在下面希望对遇到同类问题的同学有帮助。先说结论Metaspace 溢出不是 JVM 自身缺陷绝大多数情况下是应用层动态生成类、加载类但又无法卸载类最终把元空间耗尽。实验中用的方法很简单通过 CGLib 持续生成新类几分钟内就能看到 OOM: Metaspace。验证完之后才会真正理解为什么光调大MaxMetaspaceSize治标不治本。这个实验适合切过 JVM 内存模型、遇到过 Metaspace 报错的开发/运维同学也适合想系统理解元空间机制的人。我会把完整代码、启动参数、诊断命令、定位思路和解决方向都写出来你可以直接照着跑一遍。1. Metaspace 为什么还会溢出很多人的认知还停留在“永久代被移除了所以方法区不会溢出了”这是误解。JDK 8 里永久代被删除方法区的实现换成了元空间Metaspace它使用的物理内存从 JVM 堆移到了本地内存Native Memory但本质上还是用来存放类的元数据。只要你的应用在持续创建新的类元空间就会持续增长。1.1 元空间到底装了什么元空间里主要存这几类东西类的结构信息包括方法、字段、父类、接口实现等描述数据每个类加载一次就会占用一份。运行时常量池包括字符串字面量、类名、方法名、字段名的符号引用以及直接常量。类加载器的相关信息JVM 需要记录每个类是由哪个加载器加载的用于后续卸载判断。注意实例对象、数组、静态变量的值这些并不在元空间它们还是活在堆内存里。元空间存的是“类本身”的骨架信息而堆里存的是这些骨架的“实体对象”。1.2 动态生成类是元空间增长的主因普通应用启动时加载的类数量是相对固定的几万个类而已。问题是很多框架、工具库会在运行时动态生成类典型场景有这几类字节码增强工具比如 CGLib、ASM、ByteBuddy它们在运行时为目标类生成代理子类。反射调用框架通过Proxy.newProxyInstance或者反射 API 频繁生成代理类。ORM 框架在启动或运行期为实体类动态生成映射相关的辅助类。脚本引擎、表达式引擎比如 Groovy 编译脚本、QL 表达式每次执行可能都会重新编译生成新类。JSP 或者模板引擎的模块化热加载每次刷新都会产生新的类版本。上面这些场景如果使用不当就会造成“类生成速度远大于卸载速度”元空间最终被撑爆。最典型的错误就是在循环里反复创建新的类加载器或者反复执行会生成新类的逻辑又没有做好复用和缓存。1.3 元空间能不能回收、什么时候回收元空间可以回收但回收条件是“类加载器不可达 该加载器加载的所有类都不可达”。JVM 只有在发生 GC 时才会尝试卸载类而且需要满足两个前提一是类加载器本身已经不在引用链上二是这个加载器加载的类都已经失去引用。这里有个容易忽略的关键点如果某个类加载器一直被全局变量、静态引用或者线程持有它加载的类就永远不会被卸载对应的元空间数据也就永远无法释放。这正是“元空间泄漏”最常见的形态——类加载器泄漏。所以说Metaspace 溢出本质上不是容量问题是生命周期问题。你把元空间调大只是在延迟问题爆发的时间点并没有解决类反复生成且不释放的问题。2. 动手搭建一个会溢出的实验环境这部分我会带着你完整搭一套环境。先确认机器上有 JDK 8 或以上版本实验里我用的是 JDK 8如果你用更高版本也完全没问题表现是类似的。2.1 准备工具清单除 JDK 外最好备这几样东西一个可运行的 Java IDE或者直接用命令行编译IDE 只是让代码编辑更顺手。Maven 或者 Gradle用来拉取 CGLib 依赖。JDK 自带命令行工具比如jstat、jmap、jcmd。有条件的可以装一个 arthas或者直接使用visualvm查看元空间使用曲线。工具不是必须一次配齐先用 JDK 自带命令就能完成绝大部分排查工作。2.2 实验代码与启动参数我用了一段最经典的模拟代码思路很简单疯狂加载新类每个类加载完立刻失去引用理论上新类可以被卸载回收但实际元空间依然会持续膨胀。import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; public class MetaspaceOomDemo { public static void main(String[] args) { System.out.println(Metaspace OOM demo start...); int count 0; while (true) { Enhancer enhancer new Enhancer(); enhancer.setSuperclass(BaseClass.class); enhancer.setUseCache(false); enhancer.setCallback((MethodInterceptor) (obj, method, arg, proxy) - proxy.invokeSuper(obj, arg)); Object obj enhancer.create(); if (count % 1000 0) { System.out.println(Generated classes: count); } // 不要直接使用 obj让实例失去引用 } } static class BaseClass { public void doSomething() { System.out.println(base...); } } }关键细节在于setUseCache(false)关闭 CGLib 的类缓存让每次创建都会生成全新的代理类。真实业务代码里没人会这么写但很多框架在失效重试或者动态编译逻辑中确实会重复生成类效果和这个实验是一样的。启动参数这样设置java -XX:MetaspaceSize64m -XX:MaxMetaspaceSize256m \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/tmp/metaspace-oom.hprof \ -cp ./classes:./lib/cglib-3.3.0.jar:./lib/asm-9.2.jar \ MetaspaceOomDemo-XX:MaxMetaspaceSize256m是元空间上限设小一点能让实验在几分钟内见效。-XX:MetaspaceSize64m是初始的高水位线达到这个值会触发 FGC 来尝试回收元空间。注意-XX:MetaspaceSize并不是最小大小而是触发回收的阈值。很多文档把它误解成“初始大小”实际行为是当已提交的元空间使用量达到这个值时JVM 会主动做一次 Full GC尝试卸载类。调大它确实能降低 GC 频率但不会减少元空间实际占用。2.3 启动与初期现象观察运行代码后控制台会持续打印生成的类数量。我这边跑大概 1-2 分钟就能看到明显的 GC 日志和元空间使用量增长。如果加了-Xlog:gc*JDK 11 及以上或-verbose:gcJDK 8能看到频繁的 Full GC因为每次达到 MetaspaceSize 水位线JVM 会试图通过 Full GC 回收类。在刚开始的阶段FGC 频率还不高因为每次都能略微回收一点空间但很快你会发现 FGC 越来越密集直到报出异常java.lang.OutOfMemoryError: Metaspace这个报错给你两条关键信息第一元空间真的满了第二JVM 尝试过回收但回收速度跟不上生成速度。3. 完整复现与精准定位路径如果你只是看到 Metaspace OOM然后盲目调参那我建议你先把这一步走完。定位问题比解决问题重要问题在代码里参数只是表象。3.1 用命令行工具确认元空间情况OOM 发生后JVM 进程不一定立即退出如果你设置了-XX:ExitOnOutOfMemoryError,它会在 OOM 后直接退出否则进程可能还会存活一段时间趁这个窗口期赶紧采集信息。首选命令是jcmd因为它包含的信息最全jcmd pid GC.class_histogram如果输出结果里某个类出现大量实例比如大量com.example.generated.xxx说明生成的类数量异常大。但class_histogram只统计堆内实例对于判断元空间占用来说更好的工具是jstatjstat -gc pid 1000输出的 M 列代表元空间当前使用量MC 列是元空间提交容量MU 列是使用量CCSC 是压缩类空间使用量。当 MU 接近 M 且反复 FGCFull GC 次数增加问题基本实锤了。也可以一次性把老年代、元空间、GC次数都看一遍jstat -gcutil pid 1000其中 M 区间显示元空间使用率如果持续 99% 且 FGC 次数在不断增长说明元空间一直在高压状态。3.2 用 NMT 精确确认元空间占用来源jcmd自带原生内存跟踪能力可以在启动时开启java -XX:NativeMemoryTrackingsummary -cp ... MetaspaceOomDemo运行过程中用下面命令查看jcmd pid VM.native_memory summary输出里可以看到 class 区域的保留内存和已提交内存这个值会随着类生成持续上涨。对比历史上不同时点的输出如果发现 class 内存持续增长且不回落就可以确认是类元数据在膨胀。不过 NMT 也有个坑它默认会在 JVM 退出时打印一次汇总但运行中采样更实用。另外 NMT 会带来 5% 到 10% 的性能开销生产环境不建议常开实验环境无所谓。3.3 如何区分是真正的元空间耗尽还是类加载器泄漏这个问题是排查时最容易困惑的我教你怎么判断。先观察 GC 日志如果 Full GC 之后Metaspace 使用率能回落到较低水平说明类是可以回收的只是生成速度太快那问题偏向于“代码生成频率过高”。优化方向是控制生成频率加缓存。如果 Full GC 之后Metaspace 使用率几乎不动那就说明有类加载器长期存活它加载的类无法卸载。这时候要找出是谁在持有类加载器的引用。找引用的标准做法是 dump 堆jmap -dump:live,formatb,file/tmp/metaspace-oom.hprof pid然后用 MATMemory Analyzer打开堆 dump在 Dominator Tree 里找ClassLoader节点看哪些类加载器实例的持有者是活着的。你大概率能看到自定义类加载器被某个全局集合或者线程上下文持有把加载器引用清掉问题自然解决。3.4 一次典型的实际案例过程模拟项目 X 是一个接收外部规则文件的处理服务每次更新规则就重新编译一次规则脚本编译用的类加载器被一个静态 map 缓存着但 map 的 key 是规则版本号。版本号每次变化新加载器进 map旧的却因为 map 持有而无法卸载。运行三个月后Metaspace 使用量达到 1.5G某次规则推送后 OOM。排查过程就是我上面说的标准路径看到 Metaspace 报错 →jstat确认元空间居高不下 → 堆 dump 后发现类加载器数量有四十多万个 → 顺着加载器的 GC 根找到静态 map → 修改为只保留最近三个版本的加载器 → 问题消失。这个案例里元空间大小反而是次要的只要 class loader 泄漏修掉元空间自然回落到正常水平。4. 解决方案参数调整只是临时手段代码修复才是根本我在实验里把这个问题完整跑过后总结了四层解决路径按优先级从高到低排列。4.1 先诊断代码中的“类生成失控”常规做法是先扫描这几个高危点是否在循环里创建Enhancer、ProxyFactory、Proxy.newProxyInstance。是否有自定义类加载器是否被强引用长期持有。是否频繁执行 Groovy、JavaScript 等脚本编译。是否有临时类文件被复用到生产逻辑中。如果扫描后依旧没有头绪用 arthas 一段一段观察或者直接上-verbose:class看类加载日志看哪个包路径下的类在疯狂增多顺藤摸瓜找到源头。4.2 修复类加载器泄漏是核心方案大部分 Metaspace 溢出的根因是加载器泄漏而不是“生成的类总量太大”。修复思路也明确第一减少类加载器的存续时间。例如不再使用某个动态模块时直接释放对应加载器全部引用。第二使用少量复用加载器而不是每次生成。大部分场景一个加载器就够用多个加载器只会增加回收难度。第三建立缓存池。对有状态类型的类生成操作加上 key 维度的缓存重复的 key 直接返回已有类而不是重新生成。一个典型的正确用法是用单个类加载器配合字节码生成去创建一批类用完以后丢弃加载器而不是每次创建加载器又持有它。4.3 JVM 参数调整的合理姿势参数调整可以说是“止血”但止血也有技术含量。# 合理设置元空间水位线避免频繁 FGC -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m # 压缩类空间单独隔离防止互相挤压 -XX:CompressedClassSpaceSize512m # OOM 时自动 dump保留现场 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/jvm/ # 生产环境建议 GC 日志开启 -Xloggc:/data/logs/jvm/gc-%t.log -XX:PrintGCDetails -XX:PrintGCDateStampsMetaspaceSize为什么建议设置到 256M 这类偏高一点的值因为默认值是一个低水位很多服务启动时类数量大马上会触发一次 Full GC白白增加停顿调高一点可以避免启动期的无效 FGC。但不要设置成和 Max 一样大否则元空间达到上限前几乎没有预警空间出问题就是硬 OOM。还要注意一个常见坑CompressedClassSpaceSize只在开启指针压缩时才生效如果你的堆超过 32G 导致压缩指针被关闭这个参数就无效了。另外压缩类空间在 JDK 8 里如果不显式设置默认按MaxMetaspaceSize的一定比例分配调大MaxMetaspaceSize的同时建议显式指定它。4.4 生产环境如何给 GC 留出“呼吸空间”除了参数和代码还有两个容易被忽略的实操点第一合理配置并发类卸载开关。JDK 8 开始有这个参数-XX:CMSParallelInitialMarkEnabled不过更稳妥的方式是确认当前垃圾回收器是否支持类的并发卸载。如果用的 G1-XX:ClassUnloadingWithConcurrentMark默认是开启的如果被显式关闭了会造成类无法在并发周期中被卸载Metaspace 增长速度就会变快。第二监控告警要盯元空间增长趋势而不是只盯最终 OOM。我通常建议按天为单位看 Metaspace 使用率曲线如果一周内从 20% 涨到 60%说明有缓慢泄漏如果一天内从 30% 冲到 99%说明有代码级暴力生成。两者的处理策略完全不同。5. 实验复盘、参数表与实际调优经验到这里实验已经把典型问题完整走了一遍。这部分整理了速查表和一些我在实际生产项目里验证过的经验实用性比单独看某个理论高得多。5.1 Metaspace 相关参数速查表参数名作用注意事项-XX:MetaspaceSize触发 Metaspace 扩容/回收的初始水位线不是最小容量不会预占内存-XX:MaxMetaspaceSize元空间最大可用大小默认无上限生产必须显式设置-XX:MinMetaspaceFreeRatio扩容后最小空闲比例控制扩容步长避免频繁膨胀-XX:MaxMetaspaceFreeRatio扩容后最大空闲比例控制收缩容忍度-XX:CompressedClassSpaceSize压缩类空间大小堆大于 32G 时可能失效-XX:ClassUnloadingWithConcurrentMark开启/关闭并发类卸载G1 默认开启关闭会加速 Metaspace 增长-XX:HeapDumpOnOutOfMemoryErrorOOM 时输出堆快照针对 Metaspace OOM 依然有效5.2 定位 Metaspace 异常的排查顺序我建议的排查顺序是先确认进程还活着然后立刻采集jstat和 GC 日志判断元空间是不是持续增长接着用 dump 文件分析类加载器数量和引用关系最后根据持有关系找到代码中的泄漏入口。完整命令流程# 1. 看进程是否存活这里替换为你的实际 pid ps -ef | grep java # 2. 每 2 秒采样一次观察 M 区间 jstat -gcutil pid 2000 # 3. 生成堆 dump jmap -dump:live,formatb,file/tmp/dump.hprof pid # 4. 用 MAT/arthas 查找类加载器数量 # 看 ClassLoader 相关实例数量以及每个加载器的引用链 # 重点盯那些带具体业务名的类加载器比如 XxxLoader如果你没有图形环境在服务器上也可以直接看 MAT 的命令行版本不过我还是推荐把 dump 文件拉回本地分析效率和可视化都好很多。5.3 三个容易被忽视的经验细节第一点Metaspace OOM 不一定发生在“运行时位满”那一刻。JVM 给元空间申请内存是拉满到一定水位触发一次扩容尝试如果扩容失败且回收不足就会直接抛 OOM。所以日志里的报错时间点可能比元空间真正达到峰值要早一些不要只盯着峰值点。第二点-XX:MaxMetaspaceSize设得太小会让正常的类加载都变成 OOM尤其是一些框架启动时动态类特别多。很多团队把元空间上限设为 128M结果 Spring 应用刚启动到一半就挂了。我一般建议最小值至少给 256M业务复杂点的给到 512M 到 1G 都不算多。关键还是先看监控别拍脑袋。第三点动态代理的Proxy类默认是存在堆外元空间的但Proxy生成的代理类是懒加载到元空间的。每次Proxy.newProxyInstance都有可能生成新的代理类这在 Java 原生代理机制里是绕不开的所以如果你的服务大量调用该方法必须要在代码里做空接口缓存。5.4 实验后的关键认知总结这个实验跑完之后我对 Metaspace 的理解完全不一样了。元空间不是“缓存区”也不是“一般不会满的拓展空间”。它的回收绕不开类加载器生命周期只要类加载器活得久元空间就只增不减。这也是为什么彻底解决 Metaspace OOM 必须回到代码层面JVM 参数只在恢复和压制阶段起作用。我还发现一个很有意思的规律元空间使用量在使用现场监控里往往呈阶梯状上升而不是陡峭上升。每一格阶梯代表一个类加载器加载了一大批类后保持存活阶梯平台期是加载器里的类已经被加载完成但没有被卸载。如果你观察到这种形态基本可以确定是加载器持有时间问题而不是单点生成太快。6. 落地建议与后续扩展方向Metaspace 相关的知识和问题排查到这一步已经覆盖了从复现到解决的完整闭环。最后分享几个我实际执行过的落地建议。6.1 先建监控再谈优化我在某支付系统的排查经验是这样的第一天只加了元空间监控从 Grafana 上看到使用率每周增长 5% 到 8%于是提前两周就开始准备代码审查和参数调整等到真正达到告警线时问题已经修复完毕。这就是监控前置的价值。操作上可以接入 JMX 的java.lang:typeMemoryPool这个 MBean 里的Metaspace指标或者直接使用自带的基础监控系统采集 GC 日志。拿到数据后按天观察增长率最为可靠。6.2 给动态生成类的代码统一加门禁在团队的公共基础库里我给动态类生成相关的 API 上加了一层“防爆器”本质是一个计数器统计每分钟生成类数量。超过阈值时打印告警并输出调用栈。对异常高频的调用直接拒绝并返回缓存结果。这在实验里没有体现但生产价值很高。因为很多 Metaspace OOM 不是一夜之间出现的而是缓慢累积。发现“类生成量大”远比发现“元空间已满”要更早处理成本也低得多。6.3 后续可以怎么扩展如果你觉得实验还不够过瘾可以继续做两个方向。一个是改成多线程并发生成类看元空间在竞争下的波动形态顺便加-XX:MaxMetaspaceSize调整量化不同参数的影响。另一个方向是故意制造类加载器泄漏用ThreadLocal持有类加载器验证泄漏特征和 MAT 定位过程。这两个实验做完你对 Metaspace 的理解会比只看资料的同事高出几个身位。我个人实操中的体会是遇到 Metaspace OOM先不要急着改配置花半小时确认类加载器泄漏才是效率最高的路径。把问题定位到“谁的加载器还活着”比盲目调大上限踏实得多。这个实验虽然写起来简单但把进程从 OOM 到恢复的完整链路走一遍后你再看到监控里 Metaspace 曲线抬头就不会慌也不会直接重启完事而是会去翻类加载日志找那个舍不得释放的引用。
JVM 服务半夜告警排查下来是 Metaspace 内存溢出。这个报错在 JDK 8 及以后出现的频率越来越高很多人第一反应是“不是已经把永久代换成元空间了吗怎么还会溢出”。我做过一次完整的动手实验来还原这个问题从复现、定位到解决整个过程记录在下面希望对遇到同类问题的同学有帮助。先说结论Metaspace 溢出不是 JVM 自身缺陷绝大多数情况下是应用层动态生成类、加载类但又无法卸载类最终把元空间耗尽。实验中用的方法很简单通过 CGLib 持续生成新类几分钟内就能看到 OOM: Metaspace。验证完之后才会真正理解为什么光调大MaxMetaspaceSize治标不治本。这个实验适合切过 JVM 内存模型、遇到过 Metaspace 报错的开发/运维同学也适合想系统理解元空间机制的人。我会把完整代码、启动参数、诊断命令、定位思路和解决方向都写出来你可以直接照着跑一遍。1. Metaspace 为什么还会溢出很多人的认知还停留在“永久代被移除了所以方法区不会溢出了”这是误解。JDK 8 里永久代被删除方法区的实现换成了元空间Metaspace它使用的物理内存从 JVM 堆移到了本地内存Native Memory但本质上还是用来存放类的元数据。只要你的应用在持续创建新的类元空间就会持续增长。1.1 元空间到底装了什么元空间里主要存这几类东西类的结构信息包括方法、字段、父类、接口实现等描述数据每个类加载一次就会占用一份。运行时常量池包括字符串字面量、类名、方法名、字段名的符号引用以及直接常量。类加载器的相关信息JVM 需要记录每个类是由哪个加载器加载的用于后续卸载判断。注意实例对象、数组、静态变量的值这些并不在元空间它们还是活在堆内存里。元空间存的是“类本身”的骨架信息而堆里存的是这些骨架的“实体对象”。1.2 动态生成类是元空间增长的主因普通应用启动时加载的类数量是相对固定的几万个类而已。问题是很多框架、工具库会在运行时动态生成类典型场景有这几类字节码增强工具比如 CGLib、ASM、ByteBuddy它们在运行时为目标类生成代理子类。反射调用框架通过Proxy.newProxyInstance或者反射 API 频繁生成代理类。ORM 框架在启动或运行期为实体类动态生成映射相关的辅助类。脚本引擎、表达式引擎比如 Groovy 编译脚本、QL 表达式每次执行可能都会重新编译生成新类。JSP 或者模板引擎的模块化热加载每次刷新都会产生新的类版本。上面这些场景如果使用不当就会造成“类生成速度远大于卸载速度”元空间最终被撑爆。最典型的错误就是在循环里反复创建新的类加载器或者反复执行会生成新类的逻辑又没有做好复用和缓存。1.3 元空间能不能回收、什么时候回收元空间可以回收但回收条件是“类加载器不可达 该加载器加载的所有类都不可达”。JVM 只有在发生 GC 时才会尝试卸载类而且需要满足两个前提一是类加载器本身已经不在引用链上二是这个加载器加载的类都已经失去引用。这里有个容易忽略的关键点如果某个类加载器一直被全局变量、静态引用或者线程持有它加载的类就永远不会被卸载对应的元空间数据也就永远无法释放。这正是“元空间泄漏”最常见的形态——类加载器泄漏。所以说Metaspace 溢出本质上不是容量问题是生命周期问题。你把元空间调大只是在延迟问题爆发的时间点并没有解决类反复生成且不释放的问题。2. 动手搭建一个会溢出的实验环境这部分我会带着你完整搭一套环境。先确认机器上有 JDK 8 或以上版本实验里我用的是 JDK 8如果你用更高版本也完全没问题表现是类似的。2.1 准备工具清单除 JDK 外最好备这几样东西一个可运行的 Java IDE或者直接用命令行编译IDE 只是让代码编辑更顺手。Maven 或者 Gradle用来拉取 CGLib 依赖。JDK 自带命令行工具比如jstat、jmap、jcmd。有条件的可以装一个 arthas或者直接使用visualvm查看元空间使用曲线。工具不是必须一次配齐先用 JDK 自带命令就能完成绝大部分排查工作。2.2 实验代码与启动参数我用了一段最经典的模拟代码思路很简单疯狂加载新类每个类加载完立刻失去引用理论上新类可以被卸载回收但实际元空间依然会持续膨胀。import net.sf.cglib.proxy.Enhancer; import net.sf.cglib.proxy.MethodInterceptor; public class MetaspaceOomDemo { public static void main(String[] args) { System.out.println(Metaspace OOM demo start...); int count 0; while (true) { Enhancer enhancer new Enhancer(); enhancer.setSuperclass(BaseClass.class); enhancer.setUseCache(false); enhancer.setCallback((MethodInterceptor) (obj, method, arg, proxy) - proxy.invokeSuper(obj, arg)); Object obj enhancer.create(); if (count % 1000 0) { System.out.println(Generated classes: count); } // 不要直接使用 obj让实例失去引用 } } static class BaseClass { public void doSomething() { System.out.println(base...); } } }关键细节在于setUseCache(false)关闭 CGLib 的类缓存让每次创建都会生成全新的代理类。真实业务代码里没人会这么写但很多框架在失效重试或者动态编译逻辑中确实会重复生成类效果和这个实验是一样的。启动参数这样设置java -XX:MetaspaceSize64m -XX:MaxMetaspaceSize256m \ -XX:HeapDumpOnOutOfMemoryError \ -XX:HeapDumpPath/tmp/metaspace-oom.hprof \ -cp ./classes:./lib/cglib-3.3.0.jar:./lib/asm-9.2.jar \ MetaspaceOomDemo-XX:MaxMetaspaceSize256m是元空间上限设小一点能让实验在几分钟内见效。-XX:MetaspaceSize64m是初始的高水位线达到这个值会触发 FGC 来尝试回收元空间。注意-XX:MetaspaceSize并不是最小大小而是触发回收的阈值。很多文档把它误解成“初始大小”实际行为是当已提交的元空间使用量达到这个值时JVM 会主动做一次 Full GC尝试卸载类。调大它确实能降低 GC 频率但不会减少元空间实际占用。2.3 启动与初期现象观察运行代码后控制台会持续打印生成的类数量。我这边跑大概 1-2 分钟就能看到明显的 GC 日志和元空间使用量增长。如果加了-Xlog:gc*JDK 11 及以上或-verbose:gcJDK 8能看到频繁的 Full GC因为每次达到 MetaspaceSize 水位线JVM 会试图通过 Full GC 回收类。在刚开始的阶段FGC 频率还不高因为每次都能略微回收一点空间但很快你会发现 FGC 越来越密集直到报出异常java.lang.OutOfMemoryError: Metaspace这个报错给你两条关键信息第一元空间真的满了第二JVM 尝试过回收但回收速度跟不上生成速度。3. 完整复现与精准定位路径如果你只是看到 Metaspace OOM然后盲目调参那我建议你先把这一步走完。定位问题比解决问题重要问题在代码里参数只是表象。3.1 用命令行工具确认元空间情况OOM 发生后JVM 进程不一定立即退出如果你设置了-XX:ExitOnOutOfMemoryError,它会在 OOM 后直接退出否则进程可能还会存活一段时间趁这个窗口期赶紧采集信息。首选命令是jcmd因为它包含的信息最全jcmd pid GC.class_histogram如果输出结果里某个类出现大量实例比如大量com.example.generated.xxx说明生成的类数量异常大。但class_histogram只统计堆内实例对于判断元空间占用来说更好的工具是jstatjstat -gc pid 1000输出的 M 列代表元空间当前使用量MC 列是元空间提交容量MU 列是使用量CCSC 是压缩类空间使用量。当 MU 接近 M 且反复 FGCFull GC 次数增加问题基本实锤了。也可以一次性把老年代、元空间、GC次数都看一遍jstat -gcutil pid 1000其中 M 区间显示元空间使用率如果持续 99% 且 FGC 次数在不断增长说明元空间一直在高压状态。3.2 用 NMT 精确确认元空间占用来源jcmd自带原生内存跟踪能力可以在启动时开启java -XX:NativeMemoryTrackingsummary -cp ... MetaspaceOomDemo运行过程中用下面命令查看jcmd pid VM.native_memory summary输出里可以看到 class 区域的保留内存和已提交内存这个值会随着类生成持续上涨。对比历史上不同时点的输出如果发现 class 内存持续增长且不回落就可以确认是类元数据在膨胀。不过 NMT 也有个坑它默认会在 JVM 退出时打印一次汇总但运行中采样更实用。另外 NMT 会带来 5% 到 10% 的性能开销生产环境不建议常开实验环境无所谓。3.3 如何区分是真正的元空间耗尽还是类加载器泄漏这个问题是排查时最容易困惑的我教你怎么判断。先观察 GC 日志如果 Full GC 之后Metaspace 使用率能回落到较低水平说明类是可以回收的只是生成速度太快那问题偏向于“代码生成频率过高”。优化方向是控制生成频率加缓存。如果 Full GC 之后Metaspace 使用率几乎不动那就说明有类加载器长期存活它加载的类无法卸载。这时候要找出是谁在持有类加载器的引用。找引用的标准做法是 dump 堆jmap -dump:live,formatb,file/tmp/metaspace-oom.hprof pid然后用 MATMemory Analyzer打开堆 dump在 Dominator Tree 里找ClassLoader节点看哪些类加载器实例的持有者是活着的。你大概率能看到自定义类加载器被某个全局集合或者线程上下文持有把加载器引用清掉问题自然解决。3.4 一次典型的实际案例过程模拟项目 X 是一个接收外部规则文件的处理服务每次更新规则就重新编译一次规则脚本编译用的类加载器被一个静态 map 缓存着但 map 的 key 是规则版本号。版本号每次变化新加载器进 map旧的却因为 map 持有而无法卸载。运行三个月后Metaspace 使用量达到 1.5G某次规则推送后 OOM。排查过程就是我上面说的标准路径看到 Metaspace 报错 →jstat确认元空间居高不下 → 堆 dump 后发现类加载器数量有四十多万个 → 顺着加载器的 GC 根找到静态 map → 修改为只保留最近三个版本的加载器 → 问题消失。这个案例里元空间大小反而是次要的只要 class loader 泄漏修掉元空间自然回落到正常水平。4. 解决方案参数调整只是临时手段代码修复才是根本我在实验里把这个问题完整跑过后总结了四层解决路径按优先级从高到低排列。4.1 先诊断代码中的“类生成失控”常规做法是先扫描这几个高危点是否在循环里创建Enhancer、ProxyFactory、Proxy.newProxyInstance。是否有自定义类加载器是否被强引用长期持有。是否频繁执行 Groovy、JavaScript 等脚本编译。是否有临时类文件被复用到生产逻辑中。如果扫描后依旧没有头绪用 arthas 一段一段观察或者直接上-verbose:class看类加载日志看哪个包路径下的类在疯狂增多顺藤摸瓜找到源头。4.2 修复类加载器泄漏是核心方案大部分 Metaspace 溢出的根因是加载器泄漏而不是“生成的类总量太大”。修复思路也明确第一减少类加载器的存续时间。例如不再使用某个动态模块时直接释放对应加载器全部引用。第二使用少量复用加载器而不是每次生成。大部分场景一个加载器就够用多个加载器只会增加回收难度。第三建立缓存池。对有状态类型的类生成操作加上 key 维度的缓存重复的 key 直接返回已有类而不是重新生成。一个典型的正确用法是用单个类加载器配合字节码生成去创建一批类用完以后丢弃加载器而不是每次创建加载器又持有它。4.3 JVM 参数调整的合理姿势参数调整可以说是“止血”但止血也有技术含量。# 合理设置元空间水位线避免频繁 FGC -XX:MetaspaceSize256m -XX:MaxMetaspaceSize512m # 压缩类空间单独隔离防止互相挤压 -XX:CompressedClassSpaceSize512m # OOM 时自动 dump保留现场 -XX:HeapDumpOnOutOfMemoryError -XX:HeapDumpPath/data/logs/jvm/ # 生产环境建议 GC 日志开启 -Xloggc:/data/logs/jvm/gc-%t.log -XX:PrintGCDetails -XX:PrintGCDateStampsMetaspaceSize为什么建议设置到 256M 这类偏高一点的值因为默认值是一个低水位很多服务启动时类数量大马上会触发一次 Full GC白白增加停顿调高一点可以避免启动期的无效 FGC。但不要设置成和 Max 一样大否则元空间达到上限前几乎没有预警空间出问题就是硬 OOM。还要注意一个常见坑CompressedClassSpaceSize只在开启指针压缩时才生效如果你的堆超过 32G 导致压缩指针被关闭这个参数就无效了。另外压缩类空间在 JDK 8 里如果不显式设置默认按MaxMetaspaceSize的一定比例分配调大MaxMetaspaceSize的同时建议显式指定它。4.4 生产环境如何给 GC 留出“呼吸空间”除了参数和代码还有两个容易被忽略的实操点第一合理配置并发类卸载开关。JDK 8 开始有这个参数-XX:CMSParallelInitialMarkEnabled不过更稳妥的方式是确认当前垃圾回收器是否支持类的并发卸载。如果用的 G1-XX:ClassUnloadingWithConcurrentMark默认是开启的如果被显式关闭了会造成类无法在并发周期中被卸载Metaspace 增长速度就会变快。第二监控告警要盯元空间增长趋势而不是只盯最终 OOM。我通常建议按天为单位看 Metaspace 使用率曲线如果一周内从 20% 涨到 60%说明有缓慢泄漏如果一天内从 30% 冲到 99%说明有代码级暴力生成。两者的处理策略完全不同。5. 实验复盘、参数表与实际调优经验到这里实验已经把典型问题完整走了一遍。这部分整理了速查表和一些我在实际生产项目里验证过的经验实用性比单独看某个理论高得多。5.1 Metaspace 相关参数速查表参数名作用注意事项-XX:MetaspaceSize触发 Metaspace 扩容/回收的初始水位线不是最小容量不会预占内存-XX:MaxMetaspaceSize元空间最大可用大小默认无上限生产必须显式设置-XX:MinMetaspaceFreeRatio扩容后最小空闲比例控制扩容步长避免频繁膨胀-XX:MaxMetaspaceFreeRatio扩容后最大空闲比例控制收缩容忍度-XX:CompressedClassSpaceSize压缩类空间大小堆大于 32G 时可能失效-XX:ClassUnloadingWithConcurrentMark开启/关闭并发类卸载G1 默认开启关闭会加速 Metaspace 增长-XX:HeapDumpOnOutOfMemoryErrorOOM 时输出堆快照针对 Metaspace OOM 依然有效5.2 定位 Metaspace 异常的排查顺序我建议的排查顺序是先确认进程还活着然后立刻采集jstat和 GC 日志判断元空间是不是持续增长接着用 dump 文件分析类加载器数量和引用关系最后根据持有关系找到代码中的泄漏入口。完整命令流程# 1. 看进程是否存活这里替换为你的实际 pid ps -ef | grep java # 2. 每 2 秒采样一次观察 M 区间 jstat -gcutil pid 2000 # 3. 生成堆 dump jmap -dump:live,formatb,file/tmp/dump.hprof pid # 4. 用 MAT/arthas 查找类加载器数量 # 看 ClassLoader 相关实例数量以及每个加载器的引用链 # 重点盯那些带具体业务名的类加载器比如 XxxLoader如果你没有图形环境在服务器上也可以直接看 MAT 的命令行版本不过我还是推荐把 dump 文件拉回本地分析效率和可视化都好很多。5.3 三个容易被忽视的经验细节第一点Metaspace OOM 不一定发生在“运行时位满”那一刻。JVM 给元空间申请内存是拉满到一定水位触发一次扩容尝试如果扩容失败且回收不足就会直接抛 OOM。所以日志里的报错时间点可能比元空间真正达到峰值要早一些不要只盯着峰值点。第二点-XX:MaxMetaspaceSize设得太小会让正常的类加载都变成 OOM尤其是一些框架启动时动态类特别多。很多团队把元空间上限设为 128M结果 Spring 应用刚启动到一半就挂了。我一般建议最小值至少给 256M业务复杂点的给到 512M 到 1G 都不算多。关键还是先看监控别拍脑袋。第三点动态代理的Proxy类默认是存在堆外元空间的但Proxy生成的代理类是懒加载到元空间的。每次Proxy.newProxyInstance都有可能生成新的代理类这在 Java 原生代理机制里是绕不开的所以如果你的服务大量调用该方法必须要在代码里做空接口缓存。5.4 实验后的关键认知总结这个实验跑完之后我对 Metaspace 的理解完全不一样了。元空间不是“缓存区”也不是“一般不会满的拓展空间”。它的回收绕不开类加载器生命周期只要类加载器活得久元空间就只增不减。这也是为什么彻底解决 Metaspace OOM 必须回到代码层面JVM 参数只在恢复和压制阶段起作用。我还发现一个很有意思的规律元空间使用量在使用现场监控里往往呈阶梯状上升而不是陡峭上升。每一格阶梯代表一个类加载器加载了一大批类后保持存活阶梯平台期是加载器里的类已经被加载完成但没有被卸载。如果你观察到这种形态基本可以确定是加载器持有时间问题而不是单点生成太快。6. 落地建议与后续扩展方向Metaspace 相关的知识和问题排查到这一步已经覆盖了从复现到解决的完整闭环。最后分享几个我实际执行过的落地建议。6.1 先建监控再谈优化我在某支付系统的排查经验是这样的第一天只加了元空间监控从 Grafana 上看到使用率每周增长 5% 到 8%于是提前两周就开始准备代码审查和参数调整等到真正达到告警线时问题已经修复完毕。这就是监控前置的价值。操作上可以接入 JMX 的java.lang:typeMemoryPool这个 MBean 里的Metaspace指标或者直接使用自带的基础监控系统采集 GC 日志。拿到数据后按天观察增长率最为可靠。6.2 给动态生成类的代码统一加门禁在团队的公共基础库里我给动态类生成相关的 API 上加了一层“防爆器”本质是一个计数器统计每分钟生成类数量。超过阈值时打印告警并输出调用栈。对异常高频的调用直接拒绝并返回缓存结果。这在实验里没有体现但生产价值很高。因为很多 Metaspace OOM 不是一夜之间出现的而是缓慢累积。发现“类生成量大”远比发现“元空间已满”要更早处理成本也低得多。6.3 后续可以怎么扩展如果你觉得实验还不够过瘾可以继续做两个方向。一个是改成多线程并发生成类看元空间在竞争下的波动形态顺便加-XX:MaxMetaspaceSize调整量化不同参数的影响。另一个方向是故意制造类加载器泄漏用ThreadLocal持有类加载器验证泄漏特征和 MAT 定位过程。这两个实验做完你对 Metaspace 的理解会比只看资料的同事高出几个身位。我个人实操中的体会是遇到 Metaspace OOM先不要急着改配置花半小时确认类加载器泄漏才是效率最高的路径。把问题定位到“谁的加载器还活着”比盲目调大上限踏实得多。这个实验虽然写起来简单但把进程从 OOM 到恢复的完整链路走一遍后你再看到监控里 Metaspace 曲线抬头就不会慌也不会直接重启完事而是会去翻类加载日志找那个舍不得释放的引用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
