MetaspaceSize不是初始分配量而是首次GC触发阈值，设太小会导致启动期高频Full GC且无法卸载类，设太大则掩盖泄漏并诱发系统OOM；必须配合类卸载支持（如G1默认开启、CMS需显式启用）和动态类场景调优（如Spring AOP建议MetaspaceSize=256m、MaxMetaspaceSize=512m）。
元空间大小配置不是“设大就稳、设小就崩”的简单逻辑，而是直接影响类加载行为、GC节奏、内存稳定性与故障暴露效率的关键杠杆。配置不当，轻则引发频繁GC和内存抖动，重则掩盖泄漏、拖垮系统甚至触发Linux OOM Killer杀进程。
MetaspaceSize设太小：启动期高频无效GC
这个参数不是初始分配量，而是首次触发元空间GC的阈值。若远低于实际占用（比如设64m，而Spring Boot应用启动后立刻占到300m），会导致：
- 每加载一批类就触发一次Full GC，但因类加载器未回收、业务对象仍存活，GC几乎卸载不了任何类
- JVM反复扩容、申请本地内存页，加剧内存碎片，最终在系统内存紧张时分配失败，报OutOfMemoryError: Metaspace而非GC日志提示
- jstat中MU/MC比值剧烈震荡，监控指标失真，难以识别真实增长趋势
MaxMetaspaceSize设太大：掩盖泄漏，放大故障
设为2G甚至更高看似“保险”，实则埋下三重隐患：
- 类加载器持续泄漏时，元空间缓慢爬升，监控长期不告警，直到某次Full GC失败或宿主机内存耗尽才集中爆发
- 过大的上限推迟GC时机，大量已失效类元数据滞留，挤占本地内存，诱发系统级OOM
- 单点异常（如错误的Groovy脚本热编译）可瞬间生成数万类，直接打满空间，拖垮整个JVM；合理限制（如512m）反而能快速暴露问题并限流止损
没配类卸载支持：上限形同虚设
元空间能否真正释放，取决于是否满足卸载条件，而非大小限制本身：
- 必须搭配支持类卸载的GC器：CMS需-XX:+CMSClassUnloadingEnabled，G1默认开启但需确保未禁用并发标记
- Parallel GC（默认吞吐量收集器）仅在Full GC时卸载类，且默认不主动触发Full GC，极易导致元空间只增不减
- 未启用卸载时，即使设置了MaxMetaspaceSize，元空间也会持续增长直至触发OOM，限制完全失效
动态类生成场景需特别调优
Spring AOP、MyBatis Mapper代理、Lombok、字节码增强框架等，会高频生成新类，显著推高元空间消耗：
- 推荐起始值：-XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=512m
- 若存在大量反射调用或运行时编译（如Groovy、Janino），建议上探至1g，并配合-XX:SoftRefLRUPolicyMSPerMB=1000保护反射缓存
- 务必开启-Xlog:gc*,metaspace*=trace，观察日志中是否密集出现“Metadata GC Threshold”或“Class unloading”记录
