元空间不支持自动收缩，JVM不会将已分配的本地内存还给操作系统；所谓“收缩”实为通过固定大小、积极类卸载、监控驱动重启等组合策略，减少非高峰期驻留的无效元数据，间接实现物理内存释放。
元空间不支持真正的“自动收缩”——JVM 不会把已分配的本地内存主动还给操作系统。所谓“收缩”，其实是通过控制类卸载时机、限制容量上限、配合监控与外部干预，来减少非高峰期驻留的无效元数据，间接实现物理内存释放的效果。
固定大小：切断动态扩容链
这是最直接有效的前提操作。设初值与上限相等，让元空间失去伸缩能力：
- -XX:MetaspaceSize=512m -XX:MaxMetaspaceSize=512m（按实际用量选 256m/512m/1g）
- 这样 JVM 不会尝试扩容，也就避免了“扩容→Full GC→再扩容”的抖动循环
- 一旦达到 512m，仅触发一次含元数据卸载的 Full GC；若成功回收，后续无新增类加载则保持稳定
启用积极类卸载：释放逻辑空间
卸载无用类是元空间内存下降的唯一路径，需确保卸载机制真正生效：
- -XX:+ClassUnloading（Java 8u40+ 默认开启，显式声明更稳妥）
- -XX:+ClassUnloadingWithConcurrentMark（G1 垃圾收集器下启用并发类卸载）
- -XX:+UseCompressedClassPointers（64 位 JVM 下压缩 Klass 指针，减小元数据体积）
- 注意：只有当类加载器本身可被回收时，其加载的类才能卸载；Bootstrap/Platform/App 类加载器在运行期不会被回收，它们加载的类永远驻留
水位闭环调节：用 FreeRatio 控制提交内存波动
当未固定大小时（如调试阶段），可用比例参数引导 JVM 主动释放已提交但未使用的内存：
- -XX:MinMetaspaceFreeRatio=50：GC 后空闲占比低于 50%，触发扩容
- -XX:MaxMetaspaceFreeRatio=80：GC 后空闲占比高于 80%，触发收缩（即释放部分 committed 内存）
- 二者配合，把空闲比例锁在 50%–80% 区间，防止反复伸缩震荡
- 该机制只在 MetaspaceSize
监控驱动闭环：非高峰期的“伪收缩”落地
真正的物理内存释放，依赖外部可观测性与响应动作：
- 用 jstat -gc <pid> 持续采集 MU（Metaspace Used）和 MC（Metaspace Capacity）
- 当 MU 连续 10 分钟稳定在 300m 以下（假设上限为 512m），说明类加载高峰已过
- 此时可触发滚动重启，或结合 CI/CD 自动执行 JVM 重载，清空长期驻留的元数据
- 补充日志：-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 Metadata GC 日志中的 used/committed 变化
