需删除所有-xx:maxpermsize和-xx:permsize参数，替换为-xx:metaspacesize和-xx:maxmetaspacesize，并排查classloader泄漏导致的metaspace oom。
Java 8 启动报错 Unrecognized VM option 'MaxPermSize=256m' 怎么办
这是升级 JDK 8+ 后最常遇到的“第一道坎”——旧参数直接失效。JVM 不再识别 -XX:MaxPermSize 和 -XX:PermSize，强行保留会启动失败。
- 必须删掉所有含
PermSize或MaxPermSize的 JVM 参数 - 不能“只换名字”，比如把
-XX:MaxPermSize=512m改成-XX:MaxMetaspaceSize=512m就完事——元空间行为逻辑完全不同 - 如果用的是 Tomcat、Spring Boot 打包脚本或 CI/CD 配置，要全局搜索并清理，尤其注意
setenv.sh、application.yml的jvmArguments、Dockerfile 中的JAVA_OPTS
java.lang.OutOfMemoryError: Metaspace 是不是内存不够了
不是。和 PermGen OOM 类似，它反映的是类元数据泄漏，而不是物理内存耗尽。系统有几十 GB 内存，照样可能触发这个错误。
- 典型诱因：ClassLoader 没被回收（比如 Spring DevTools 热重启后旧 ClassLoader 仍被线程或静态引用持有）
- 动态代理泛滥：
CGLIB Enhancer或反复调用Proxy.newProxyInstance生成新类，又没缓存 - 第三方 agent “假卸载”：某些监控 SDK 在应用 shutdown 时漏掉
Instrumentation.removeTransformer或未清理自定义 ClassLoader - 验证方式：用
jcmd <pid> VM.native_memory summary</pid>查看Metaspace区域增长趋势；或 dump heap 后用 MAT 检查ClassLoader实例数是否持续上涨
-XX:MetaspaceSize 和 -XX:MaxMetaspaceSize 到底怎么设
这两个参数不控制“最大能用多少”，而是控制“什么时候开始认真 GC”。默认值太保守，容易引发早期频繁 Full GC。
-
-XX:MetaspaceSize是触发首次 Metaspace GC 的阈值（JDK 8 默认约 20.8MB），建议设为128m～256m，避免刚启动就 GC -
-XX:MaxMetaspaceSize是硬上限（默认 unlimited），必须设，否则可能吃光系统内存；生产环境推荐512m～1g，视应用类数量而定 - 不要设
-XX:MinMetaspaceFreeRatio/-XX:MaxMetaspaceFreeRatio这类高级调参项——它们对大多数业务无实质改善，反而增加不确定性 - 示例合规参数：
-Xms2g -Xmx2g -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=1g -XX:+UseG1GC
为什么元空间不用堆内存，却还要管它
因为元空间虽然用的是本地内存（native memory），但它的生命周期、分配/释放节奏仍由 JVM 控制，并受 GC 机制影响——不是“扔给 OS 就不管了”。
立即学习“Java免费学习笔记（深入）”；
- 类卸载仍依赖 GC：只有当 ClassLoader 对象本身被回收，它加载的类元数据才可能从 Metaspace 清理；所以 ClassLoader 泄漏 = Metaspace 泄漏
- Metaspace GC 不是独立的：它随老年代 GC 或 G1 Mixed GC 附带执行，不会单独触发；这意味着 GC 策略（如是否启用
-XX:+UseG1GC）间接影响元空间回收效率 - 本地内存 ≠ 无限：Linux 下受
ulimit -v（虚拟内存）或ulimit -d（数据段）限制，容器环境还受 cgroup memory limit 约束
