核心是盯住used、committed、capacity三值及metadata gc threshold、class unloading两类触发原因：used持续上升说明classloader未回收，used近capacity但capacity不涨表明maxmetaspacesize触顶，突增后骤降多因classloader批量卸载；metadata gc threshold高频出现提示动态代理失控，class unloading后used明显下降才是健康信号。
看 GC 日志里的元空间信息，核心是盯住三组数字和两类触发原因，不是只看“有没有 GC”，而是看“用了没放、为啥不放”。
重点关注 Metaspace 后的三个值
日志中形如 [Metaspace: 20599K->20599K (1067008K)]，括号内依次是：
- used（已用）：当前加载类元数据实际占用大小。持续上升不回落，说明类加载器没被回收，常见于 Spring AOP/CGLIB 动态代理、热部署、OSGi 等场景；
- committed（已提交）：JVM 向操作系统申请并锁定的本地内存大小。它会随 used 增长而缓慢扩大，但不会自动缩回；
-
capacity（容量）：当前可分配上限，由
-XX:MaxMetaspaceSize限制。若 used 接近 capacity 但 capacity 不涨，说明已达上限，JVM 会反复触发 Full GC 尝试回收。
识别关键触发原因字段
GC 日志中括号内的说明文字直接揭示问题根源：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
-
Metadata GC Threshold：元空间使用量突破内部高水位（默认由
-XX:MetaspaceSize设定），触发 Young GC + 元数据回收尝试。高频出现（如每分钟多次），大概率是动态代理类生成失控； -
Full GC (Metadata GC Threshold)：元空间触顶且 Young GC 无效，被迫执行 Full GC。若回收前后 used 几乎不变（如
245120K->245088K），说明类加载器仍可达，代理类无法卸载； - Class unloading：健康信号。表示 ClassLoader 被成功回收，关联元数据批量释放。此时 used 应明显下降（如下降数 MB），且日志中常伴随 “Classes unloaded: X”。
结合 jstat 快速交叉验证
单靠日志易误判，建议实时用命令辅助确认趋势：
-
jstat -gc <pid></pid>：关注 MU（Metaspace Used）是否持续上涨、MC（Metaspace Capacity）是否同步扩大、CCSU（Compressed Class Space Used）是否同步增长——三者齐涨，说明新类在不断加载； -
jstat -class <pid></pid>：观察 loaded（已加载类数）是否只增不减。若 Full GC 后 loaded 未减少，基本可判定类加载器泄漏； - 搭配
-XX:+PrintClassLoaderStatistics启动，GC 日志中会多出类加载器统计行，能直接看到加载器数量是否异常增长。
回收失败的典型表现
元空间不释放，本质是 ClassLoader 还活着。以下情况会导致“用了不放”：
- 自定义 ClassLoader 被 static 字段强引用；
- ThreadLocal 中存了该加载器加载的类实例；
- 第三方库（如某些 JDBC 驱动、Logback）缓存了 Class 或 ClassLoader；
- JNI 代码持有 Java 类的 GlobalRef。
此时 GC 日志中会出现大量 [GC (Metadata GC Threshold)]，但 [Metaspace: X->X] 的 used 值几乎不变，就是泄漏明确信号。
