元空间OOM主因是类加载与卸载异常，关键在满足三条件：类实例全回收、类加载器被回收、Class对象无强引用；排查需结合-XX:+PrintMetaspaceStatistics、jcmd VM.classloader_stats及MAT分析引用链。
System.gc() 本身不能直接排查元空间残留，它只是建议 JVM 进行一次全局垃圾回收（包括元空间），但不保证触发元空间的类卸载。真正排查动态类加载导致的元空间残留，关键在于确认类是否被成功卸载、哪些类还驻留在元空间、以及为什么没被卸载。System.gc() 只是辅助验证环节中的一个操作步骤。
确认元空间使用趋势与类数量变化
启用 JVM 参数观察运行时行为，这是排查的第一步：
- -XX:+PrintGCDetails -XX:+PrintGCTimeStamps：查看 GC 日志中 Metaspace 区域的回收记录（注意不是 Full GC 就一定清理元空间）
- -XX:+PrintMetaspaceStatistics：JDK 11+ 支持，每次 GC 后打印元空间详细统计（已用/已提交/最大容量、加载类数、卸载类数）
- -XX:+TraceClassLoading -XX:+TraceClassUnloading：输出每个类加载和卸载事件，可快速定位“只加载不卸载”的类名
主动触发并观察类卸载是否发生
在动态加载一批类（如通过 URLClassLoader 加载新版本 Jar）并显式释放其引用后，可调用 System.gc() 辅助验证卸载效果：
- 确保 ClassLoader 实例及其加载的所有类实例（包括静态字段引用的对象）全部不可达
- 调用 System.gc()，紧接着立即执行 ManagementFactory.getMemoryPoolMXBean("Metaspace") 查询使用量
- 对比调用前后 getUsage().getUsed() 和 getUsage().getCommitted() 是否下降；若未降，说明类未卸载
- 结合 jstat -gc <pid> 持续监控，例如每秒刷新：jstat -gc -h10 <pid> 1000
定位残留类及其 ClassLoader 引用链
如果元空间持续增长且不下降，需深入分析哪些类卡住了：
- 用 jcmd <pid> VM.native_memory summary scale=MB 查看元空间总用量（JDK 8+）
- 用 jmap -clstats <pid> 列出所有 ClassLoader 及其加载的类数量（JDK 8）、或用 jcmd <pid> VM.classloader_stats（JDK 11+）
- 用 jmap -histo:live <pid> | grep YourClassLoaderName 粗略检查是否有残留实例
- 必要时生成堆转储（jmap -dump:format=b,file=heap.hprof <pid>），用 JProfiler/Eclipse MAT 分析谁持有 ClassLoader 的强引用（如静态 Map、线程局部变量、未关闭的资源监听器等）
避免依赖 System.gc() 的典型误区
很多团队误以为调用 System.gc() 就能“清掉元空间”，实际常见问题如下：
- ClassLoader 被静态集合（如 ConcurrentHashMap
）长期持有 → 清空该集合再 gc - 动态类中有静态字段引用了外部对象，而该对象又反向引用了 ClassLoader → 检查静态初始化逻辑
- 使用了 CGLIB/ASM 生成类但未显式清理 GeneratedClassLoader 或未关闭 ClassWriter
- JDK 自身缓存（如 StringTable、ConstantPool、JIT 编译代码）也可能间接阻止类卸载 → 配合 -XX:+AlwaysPreTouch 和 -XX:+UseStringDeduplication 观察影响
