元空间健康需盯住GC日志中Metaspace的used、committed、capacity三值：used持续上升说明ClassLoader未回收；used近capacity但capacity不涨表明MaxMetaspaceSize触顶；突增后骤降多因ClassLoader批量卸载。
元空间（Metaspace）是 JDK 8+ 中存放类元数据的本地内存区域，不占用堆空间，但它的异常增长会直接引发 OutOfMemoryError: Metaspace，且容易被误判为堆内存问题。分析其使用与回收，关键不在“有没有GC”，而在于“为什么没回收”或“为什么反复触发GC”。
怎么看元空间是否健康？盯住三个数字
GC日志中元空间条目形如：
[Metaspace: 20599K->20599K (1067008K)]
它包含三组值：已用（used）、已提交（committed）、总容量（capacity）。重点关注：
- used 值持续上升且不回落：说明类加载器未被回收，常见于热部署、OSGi、频繁反射生成代理类（如 Spring AOP/CGLIB、Jackson 动态序列化）
-
used 接近 capacity，但 capacity 不涨：说明设置了
-XX:MaxMetaspaceSize且已触顶，JVM 会强制 Full GC 尝试回收元数据 - used 突增后又骤降：大概率是某次类加载失败后回滚，或批量卸载了某个 ClassLoader（如 Web 应用重启）
识别元空间触发的 GC 类型
元空间相关 GC 在日志中明确标注原因：
-
[GC (Metadata GC Threshold)]：元空间使用量突破内部高水位线（由
-XX:MetaspaceSize初始化设定），触发一次 Young GC + 元数据回收尝试 -
[Full GC (Metadata GC Threshold)]：元空间已达上限（
MaxMetaspaceSize），且 Young GC 无法释放足够空间，被迫执行 Full GC - [GC (Class Unloading)]：类加载器被回收，关联元数据批量释放——这是健康的信号，说明卸载机制生效
元空间回收失败的典型表现
不是所有元空间占用都能被回收，核心约束是：类加载器必须不可达。以下情况会导致“用了不放”：
JavaStoryDevelop
下载
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
- 静态持有 ClassLoader 引用（如自定义 ClassLoader 被 static 字段强引用）
- ThreadLocal 中存有该 ClassLoader 加载的类实例
- 第三方库（如某些数据库驱动、日志框架）缓存了 ClassLoader 或 Class 实例
- JNI 代码中长期持有 Java 类的 GlobalRef
此时即使 Full GC 后，[Metaspace: X->X] 中 used 值不变，且伴随频繁 Metadata GC Threshold 日志，就是泄漏征兆。
调优建议：从参数到代码
避免盲目加大 MaxMetaspaceSize，先确认是否真需要那么多类：
- 初始值设合理：
-XX:MetaspaceSize=128m（避免早期频繁扩容触发 GC） - 上限要可控：
-XX:MaxMetaspaceSize=256m（防止无节制吞噬本地内存） - 监控辅助：
-XX:+PrintGCDetails -Xloggc:gc.log，配合jstat -gc <pid>查看MU（Metaspace Used）和MC（Metaspace Capacity） - 代码层面：热部署场景下，确保每次 reload 都创建新 ClassLoader，并显式 null 掉旧引用；避免在 static 块中缓存 Class 或 ClassLoader
