OutOfMemoryError: Metaspace 表明元空间不足，非堆内存问题；需通过GC日志、jstat、jmap -clstats定位类加载器泄漏或MaxMetaspaceSize过小，并合理设置MetaspaceSize与MaxMetaspaceSize。
Metaspace 内存溢出时 java.lang.OutOfMemoryError: Metaspace 怎么快速定位
这不是堆内存问题，OutOfMemoryError: Metaspace 一出现，说明类加载器没释放、动态生成类（如 Spring CGLIB、Jackson 反序列化、Groovy 脚本）太多，或 MaxMetaspaceSize 设得太小压根不够用。
先别急着调参，用这几步确认根源：
- 加 JVM 参数
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps，看 GC 日志里是否频繁触发Metadata GC Threshold—— 频繁就说明元空间在反复扩容收缩，类卸载不干净 - 用
jstat -gc <pid></pid>查MU（Metaspace used）和MC（Metaspace capacity），如果MU接近MC且持续上涨，基本是类泄漏；如果MU稳定但MC被撑到MaxMetaspaceSize，说明上限卡死了 - 用
jmap -clstats <pid></pid>（JDK 8u40+）看各 ClassLoader 加载了多少类，重点关注sun.misc.Launcher$AppClassLoader之外的自定义类加载器——热部署、OSGi、插件化场景下容易堆积
MaxMetaspaceSize 设多少才合理？不是越大越好
默认不限制（MaxMetaspaceSize 为 -1），意味着元空间可无限向 OS 申请内存，最终可能把机器物理内存吃光，引发 OOM Killer 杀进程。必须设，但不能拍脑袋。
参考值来自实际压测 + 观察：
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
- 启动后稳定运行时，用
jstat -gc <pid></pid>记下MC值（比如 120MB），再留 30%~50% 余量，设成-XX:MaxMetaspaceSize=180m - 如果应用大量使用反射、字节码生成（如 Lombok 编译期注解、MyBatis Mapper 动态代理），初始值建议不低于
256m，否则启动阶段就可能触发首次 Metaspace GC - 注意：设了
MaxMetaspaceSize后，一旦达到阈值又无法卸载类，就会直接 OOM；不设则靠 GC 自动扩缩容，但风险转嫁给系统稳定性
MetaspaceSize 和 MaxMetaspaceSize 的区别与配合
MetaspaceSize 是触发首次 Metaspace GC 的初始阈值，不是“初始分配大小”——元空间初始只占很小一块内存，随着类加载慢慢增长，直到达到 MetaspaceSize 才会触发 GC 尝试回收无用类元数据。
常见误配：
- 只设
MaxMetaspaceSize不设MetaspaceSize：默认值是 20.8MB（JDK 8u40），小项目够用，但微服务类多的应用，刚启动几十秒就 GC，影响首屏响应 - 把
MetaspaceSize设得比MaxMetaspaceSize还大：JVM 启动失败，报错Error: Could not create the Java Virtual Machine. - 推荐配法：
-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=256m，让 GC 在中等压力下介入，避免过早或过晚
Spring Boot 应用特别容易踩的 Metaspace 坑
Spring Boot 默认启用 spring.devtools.restart 和大量自动配置，每次热重启都会创建新 LaunchedURLClassLoader，旧类加载器若被引用就无法卸载，元空间缓慢泄漏。
实操建议：
- 生产环境务必关闭 devtools：
spring.devtools.restart.enabled=false，否则MaxMetaspaceSize再大也扛不住反复 redeploy - 检查是否滥用
@Configuration+@Bean动态注册大量 Bean —— 某些 SDK（如老版本 Druid）会在运行时生成代理类，每建一个连接池就多几百个类 - 升级到 Spring Boot 2.7+ 或 3.x，其内部对 CGLIB 代理做了缓存优化，类生成量明显下降；老版本建议显式配置
spring.aop.proxy-target-class=true减少接口代理切换带来的重复生成
Metaspace 调优真正的难点不在参数数字，而在于判断“哪些类该卸载却没卸载”。GC 日志里的 Full GC (Metadata GC Threshold) 是线索，jmap -clstats 是证据，类加载器生命周期管理才是根因——这点最容易被跳过，直接去调 MaxMetaspaceSize。
