spring boot 启动频繁 full gc 很可能是 metaspace 不足导致的“假性 full gc”，因 jdk 8+ 中 metaspace 分配失败会先触发 full gc 再扩容，可通过 gc 日志中的“metadata gc threshold”及 jstat 的 mu/mc 比值确认，并建议基于实测峰值设置 -xx:metaspacesize。
Spring Boot 启动阶段频繁 Full GC，如果日志显示发生在应用刚加载完大量类（尤其是用了大量 Starter、反射、动态代理或字节码增强框架如 Lombok、MyBatis Plus、Spring AOP）之后，且 jstat -gc 观察到 MU（Metaspace 使用量）快速逼近 MC（Metaspace 容量），随后触发 Full GC —— 这大概率是 Metaspace 不足引发的“假性 Full GC”，并非老年代真满了。
为什么 Metaspace 不足会触发 Full GC？
JDK 8+ 移除了永久代（PermGen），改用本地内存管理的 Metaspace。但它的扩容不是完全无感的：当类元数据分配失败时，JVM 会先尝试触发一次 Full GC（目的是回收已卸载类的元数据空间），GC 完发现仍不够，才真正扩容 Metaspace。这个“先 GC 再扩容”的机制，会让启动期出现多次无意义的 Full GC，拖慢启动、干扰监控、掩盖真实问题。
怎么确认是 Metaspace 导致的？
启动时加参数开启详细 GC 日志和 Metaspace 跟踪：
- -Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 10+）
- -XX:+PrintGCDetails -XX:+PrintGCTimeStamps（JDK 8/9）
- -XX:+PrintGCTimeStamps -XX:+PrintStringDeduplicationStatistics（辅助判断）
查看 gc.log 中是否频繁出现类似这样的组合：
- [GC (Metadata GC Threshold) ...] → 表明因元数据达到阈值触发
- [Full GC (Metadata GC Threshold) ...] → 明确由 Metaspace 引发
- 同时 jstat -gc
输出中 MU / MC 比值长期 >95%，且 FGCT（Full GC 总耗时）集中在启动前30秒
怎么调 -XX:MetaspaceSize？关键不是“设多大”，而是“设对时机”
MetaspaceSize 是触发首次 Metaspace 扩容的初始阈值（不是初始分配大小）。设得太小（默认约 20–24MB），类一多就立刻触发 GC；设得太大，又浪费内存或延迟真正问题暴露。建议按以下方式分步调优：
-
先测基线：不加任何 Metaspace 参数启动，用 jstat -gc
1s 持续观察启动过程中的 MU 峰值，记下稳定后的最大值（比如 180MB） - 保守初设：取实测峰值的 1.2–1.5 倍，例如设为 -XX:MetaspaceSize=256m；同时配 -XX:MaxMetaspaceSize=512m 防止无限增长
- 验证效果：重启后检查 gc.log 是否还出现 Metadata GC Threshold 相关的 Full GC；jstat 中 MU 应平稳上升至某值后不再触碰 MC 边界
- 上线前压测确认：在预发环境模拟全量类加载（如 warm-up 接口 + 多实例并发启动），确保该值在不同 JVM 实例间稳定有效
比调参更关键的三件事
单纯调大 MetaspaceSize 只治标。若你发现即使设到 512m 仍频繁触发，说明存在深层问题：
- 检查类加载泄漏：热部署（DevTools）、OSGi、自定义 ClassLoader 未正确释放，导致 Class 对象无法卸载 → 即使扩容也迟早打满
- 精简依赖树：运行 mvn dependency:tree -Dverbose | grep starter，删掉不用的 Spring Boot Starter（如 webflux 项目引入 spring-boot-starter-web）
- 禁用非必要字节码增强：Lombok 的 @Data、@Builder 在编译期生成大量桥接方法；MyBatis Plus 的自动注入 mapper 也会增加类数量；可考虑用 @Accessors(chain = true) 替代部分 Builder 场景，减少生成类
Metaspace 优化见效快，但必须结合类加载行为分析才有长期价值。
