Java 8 彻底移除永久代是因它与GC协同差、易触发OutOfMemoryError，改用基于本地内存的元空间替代，由-XX:MaxMetaspaceSize控制，默认无上限，需防泄漏。
Java 8 为什么彻底移除了永久代（PermGen）
因为永久代设计上无法与垃圾回收机制协同，容易触发 java.lang.OutOfMemoryError: PermGen space，尤其在热部署、大量反射或动态类生成场景下。JDK 8 不是“改名”，而是用元空间（Metaspace）替代——它从 JVM 堆外内存（本地内存）分配，不再受 -XX:MaxPermSize 限制，改由 -XX:MaxMetaspaceSize 控制。
关键区别在于：永久代是堆的一部分，受 GC 管理；元空间则使用本地内存，仅对类元数据做轻量级回收（如类卸载），且默认无上限（可能耗尽系统内存）。
- 旧参数
-XX:PermSize和-XX:MaxPermSize在 JDK 8+ 已被忽略，设了也不生效 - 若应用升级后仍报
OutOfMemoryError，大概率是忘了配-XX:MaxMetaspaceSize，导致元空间无限扩张 - Spring Boot 2.x + Tomcat 8+ 热重启频繁时，未卸载的 ClassLoader 会持续占用元空间，必须配合
-XX:+TraceClassUnloading排查
Metaspace 内存到底存在哪儿
元空间物理上位于本地内存（native memory），不是堆，也不是直接映射到操作系统的虚拟内存区；它是通过 mmap 分配的多个不连续内存块，由 JVM 自己管理。这意味着：
-
jstat -gc <pid></pid>输出中不再有PC（Permanent Capacity）字段，取而代之是MC（Metaspace Capacity）、MU（Metaspace Used） -
jmap -histo:live <pid></pid>不统计类元数据大小，要查元空间用量得用jstat -gccapacity <pid></pid>或 JMX 的java.lang:type=MemoryPool,name=Metaspace - Linux 下可通过
pmap -x <pid></pid>观察大块 anon 匿名内存，其中就包含元空间分配区
哪些操作真正触发 Metaspace 分配
不是每个 new 类实例都会动元空间，只有加载、链接、初始化类结构时才写入元空间。典型触发点包括：
立即学习“Java免费学习笔记（深入）”；
- 首次调用
Class.forName("xxx")或通过类加载器loadClass() - 使用
Unsafe.defineAnonymousClass()（如 Lambda、动态代理生成类） - 反射调用
Method.setAccessible(true)后，JVM 可能缓存解析后的字节码结构 - 使用 CGLIB 或 ByteBuddy 运行时生成类（如 Spring AOP、Mockito）
注意：String.intern() 在 JDK 7+ 已移到堆中，和元空间无关；但 Class> clazz = obj.getClass() 不分配新元数据，只是引用已有项。
排查 Metaspace 泄漏的实用路径
泄漏本质是 ClassLoader 持有已加载类的引用，导致类无法卸载，元空间持续增长。常见于 Web 容器反复部署、OSGi、或自定义类加载器未正确释放。
- 启用
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察日志中是否出现Full GC (Metadata GC Threshold)—— 这说明元空间快满了，触发了 Full GC 来尝试回收 - 用
jcmd <pid> VM.native_memory summary scale=MB</pid>查看Internal区域是否异常偏高（元空间归在此类） - dump 后用
jhat或 MAT 打开heap.hprof，按java.lang.ClassLoader分组，找数量突增的子类加载器实例 - 确认类加载器是否持有
ThreadLocal、静态集合、或未关闭的资源（如 JDBC Driver 注册未反注册）
最常被忽略的一点：即使代码里显式调用了 ClassLoader.close()，若该加载器加载的类仍有活跃引用（比如某个单例对象持有了它的 Class 实例），JVM 仍不会卸载这些类，元空间也不会释放。
