PermGen 在 JDK 7 及之前会 OOM 是因为其大小固定且与堆共享内存，类加载过多（如热部署、动态代理）时无法扩容，GC 回收弱，ClassLoader 泄漏导致元数据持续累积。
PermGen 在 JDK 7 及之前为什么会 OOM？
方法区在 JDK 7 及以前叫 PermGen（永久代），它和堆共享 JVM 启动时分配的连续内存空间，但大小固定。一旦加载的类太多（比如热部署、大量动态代理、Groovy/Scala 等动态语言生成类），java.lang.OutOfMemoryError: PermGen space 就会直接报出来。
常见触发场景：Spring Boot 应用反复重启、Tomcat 部署多个 WAR 包、使用 CGLIB 或 ByteBuddy 大量生成代理类。
-
-XX:MaxPermSize是唯一调参手段，但治标不治本——设太大浪费内存，设太小容易崩 - GC 对
PermGen的回收很弱，尤其 ClassLoader 泄漏时，老年代都空着，PermGen却一直涨 - JDK 7 开始把字符串常量池（
StringTable）从PermGen挪到了堆里，这是过渡信号
JDK 8 的 Metaspace 到底怎么管内存？
JDK 8 彻底移除了 PermGen，换成基于本地内存（native memory）的 Metaspace。它不再受 JVM 堆参数约束，而是默认无上限地向操作系统申请内存，OOM 错误也变成了 java.lang.OutOfMemoryError: Metaspace。
关键不是“不会 OOM”，而是“OOM 原因变了”：现在更可能是元数据泄漏（如 ClassLoader 没被回收），或没设任何限制导致吃光系统内存。
立即学习“Java免费学习笔记（深入）”；
- 用
-XX:MaxMetaspaceSize控制上限（必须显式设置，否则等于 OS 剩余内存） -
-XX:MetaspaceSize是初始触发 GC 的阈值（类似年轻代的InitialHeapSize），不是初始分配量 - GC 会回收无用类的元数据，但前提是对应的
ClassLoader被回收——这点比 PermGen 更严格，也更容易暴露泄漏
为什么 JDK 9+ 的 ClassDataSharing（CDS）能加速启动？
CDS 不是方法区本身的演进，但它依赖 Metaspace 的架构才能落地。它的核心是把常用 JDK 类（如 java.lang.*）的元数据序列化到共享归档文件（classes.jsa），JVM 启动时直接 mmap 进内存，跳过解析、验证、链接等步骤。
这只有在元数据和堆分离（即 Metaspace）的前提下才安全可靠；PermGen 和堆混在一起，无法做只读共享映射。
- 启用方式：先执行
java -Xshare:dump生成classes.jsa，再用java -Xshare:on启动 - 仅对 bootstrap class loader 加载的类生效，应用类需用
Application Class-Data Sharing（JDK 10+，需额外编译） - 注意
-XX:+UseCompressedClassPointers必须开启（默认开），否则 CDS 失效
排查 Metaspace 泄漏最有效的三个命令
别急着加 -XX:MaxMetaspaceSize 压测，先确认是不是真泄漏。JDK 自带工具比堆 dump 更快定位元数据问题。
- 看实时用量：
jstat -gc <pid></pid>中的MU（Metaspace used）、MC（Metaspace capacity）、CCSU（Compressed Class Space used）三列持续上涨且不回落 - 查加载类数：
jcmd <pid> VM.native_memory summary scale=MB</pid>里看Class行，配合jcmd <pid> VM.class_hierarchy -all</pid>看类分布 - 抓泄漏根源：
jmap -clstats <pid></pid>输出每个 ClassLoader 实例加载的类数量，重点找数量异常高、且alive为false却没被回收的 ClassLoader
Metaspace 的“自动扩容”特性会让问题延迟暴露——可能压测跑了 2 小时才爆，但泄漏点早在第一次部署就埋下了。
