必须显式设置-XX:MetaspaceSize与-XX:MaxMetaspaceSize为相等值（如256m/512m），禁用动态扩容，避免“扩容→Full GC→再扩容”恶性循环；按服务类型分级设定：普通微服务256m～512m，代理密集型512m～1g，轻量服务128m～256m，并启用-XX:+UseCompressedClassPointers及配套监控。
生产环境元空间必须显式限制，不能依赖默认无上限行为。核心是固定初始值与最大值相等，并结合类加载特征做分级设置。
统一设初值与最大值
避免元空间动态扩容触发 Full GC，消除运行时不确定性：
- -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m 是最简稳态配置
- 两者不等会导致首次达到 MetaspaceSize 就触发 GC，后续持续扩容缩容，加剧 GC 波动
- JDK 8/11/17 均适用，Java 17 虽支持更积极卸载，但不改变“需手动限幅”的前提
按服务类型分级设定大小
脱离业务场景谈数值等于纸上谈兵：
- 普通 Spring Boot 微服务：256m～512m（含常规注解、AOP、少量代理）
- 规则引擎、Groovy 脚本、CGLIB/Hibernate 代理密集型：512m～1g
- 轻量后台或测试服务：128m～256m（需配合 jstat 验证是否够用）
- 切忌为“保险”盲目设 2g+——元空间超 1g 通常意味着类加载失控
启用压缩类指针降低开销
在 64 位 JVM 中减少每个 Class 元数据的内存 footprint：
- 添加 -XX:+UseCompressedClassPointers（JDK 8u60+ 默认开启，显式声明更明确）
- 该参数需与 -XX:+UseCompressedOops 协同生效，堆 ≤32GB 时自动启用
- 若堆已超 32GB，应先审视是否真需如此大堆，而非强行开启压缩
配套监控与诊断参数
配置不是终点，可观测性才是闭环关键：
- 加 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，定位 Metadata GC Threshold 日志行
- 用 jstat -gc
实时看 MUS（Metaspace Used）、MC（Metaspace Capacity）趋势 - 通过 JMX 查询 java.lang:type=MemoryPool,name=Metaspace 的 used/max 属性，接入 Prometheus 报警
