元空间使用本地内存仍会OOM，因其受操作系统内存限制且类加载器泄漏导致元数据无法卸载；需通过jstat/jcmd确认占用、设-XX:MaxMetaspaceSize限制上限、根治类加载器泄漏。
元空间（Metaspace）本身不占用堆内存，而是使用本地内存（Native Memory），但它依然会溢出——这不是矛盾，而是机制使然。关键在于：**元空间的“物理内存”分配受操作系统限制，且其增长依赖类加载器行为，而类加载器若未被回收，其加载的类元数据就永远驻留，最终耗尽可用本地内存。**
为什么用的是本地内存，还会 OOM？
Metaspace 虽从本地内存分配，但不是无限可伸缩：
- 操作系统对单个进程的虚拟地址空间和物理内存有硬性上限（如 Linux 的
ulimit -v或ulimit -m，或容器中 cgroup memory.limit_in_bytes）； - HotSpot 默认不限制 Metaspace 大小（
-XX:MaxMetaspaceSize未设时为无上限），但实际能申请到多少，取决于剩余本地内存是否足够； - 更隐蔽的是：**类加载器泄漏**——比如 Web 应用热部署、OSGi、反射生成大量代理类（CGLIB/ByteBuddy）、或自定义 ClassLoader 持有静态引用，导致类加载器无法被 GC，其所加载的所有类元数据（包括常量池、字段、方法字节码等）全部滞留在 Metaspace 中，持续累积。
怎么破这个“用了本地内存还溢出”的死结？
不能只加参数硬扛，要分三层应对：
-
第一层：确认是不是真 Metaspace OOM——看错误日志是否为
java.lang.OutOfMemoryError: Metaspace，并检查jstat -gc <pid>中MU（Metaspace used）是否持续上涨、MC（Metaspace capacity）是否逼近MX（max capacity）； -
第二层：限制+监控，暴露问题——显式设置
-XX:MaxMetaspaceSize=256m（根据应用类规模合理预估），配合-XX:+PrintGCDetails观察 Metaspace GC 是否频繁触发，再用jcmd <pid> VM.native_memory summary查看本地内存各区域（including metaspace）真实占用； -
第三层：根治泄漏源头——导出类加载器快照：
jmap -clstats <pid>看哪些 ClassLoader 实例数异常多；用jcmd <pid> VM.class_hierarchy或 MAT 分析heap.hprof中ClassLoader对象的引用链；重点排查：静态持有 ClassLoader、ThreadLocal 存储了 ClassLoader、未释放的 ServletContext、未 unregister 的 MBean 等。
一个典型误操作陷阱
很多人发现 Metaspace OOM 后，第一反应是加大 -XX:MaxMetaspaceSize。这只会推迟崩溃时间，甚至掩盖泄漏——因为更大的上限意味着更多坏类加载器能活更久，最终一次性压垮整个进程的本地内存，连带影响堆外缓冲区（DirectByteBuffer）、JIT 编译缓存等其他本地内存消费者，引发连锁 OOM。
