元空间使用率与类加载个数非线性但强相关，因每个类元数据“重量”差异大：空POJO仅20–50KB，而Spring Bean、CGLIB代理或Groovy脚本类可达100–500KB以上；真正决定占用的是类定义复杂度、类加载器粒度、是否启用压缩类空间及类卸载情况。
元空间使用率和类加载个数**不是线性关系，但存在强相关性**——类数量增加通常推高使用率，但具体增幅取决于每个类的元数据“重量”，而非单纯计数。
为什么不能只看类个数？
元空间存储的是类的完整元数据：方法字节码、常量池、字段/方法签名、注解、运行时常量池引用等。不同类占用差异极大：
- 一个空的 POJO 类（仅字段+getter）可能只占 20–50 KB
- 一个含大量泛型、嵌套注解、Lombok 生成代码的 Spring Bean，可能达 100–300 KB
- CGLIB 生成的代理类或 Groovy 编译的脚本类，因重复结构+调试信息，单个可达 500 KB 以上
真正影响使用率的关键变量
决定元空间实际占用的，是以下四类因素的组合：
- 类定义复杂度：方法数量、字节码长度、泛型深度、注解数量
- 类加载器粒度：每个类加载器维护独立的元数据空间；100 个类由 1 个 loader 加载，比由 100 个 loader 各加载 1 个更省空间（避免 loader 自身开销和隔离冗余）
- 是否启用压缩类空间：Klass 结构体（约 2KB/类）存于 Compressed Class Space，不计入 Metaspace Used，但会占用总本地内存
- 类是否被卸载：Loaded Class Count 持续上涨而 Unloaded Count 几乎为 0，说明元空间使用率会单向爬升，与类个数呈准线性关系
监控时该关注什么指标？
不要只盯“已加载类数”，要结合使用率趋势交叉判断：
- 用
jstat -gc <pid>查看 MU（Metaspace Used） 和 MC（Metaspace Capacity），计算使用率 ≈ MU / MC × 100% - 同步观察 MCL（Loaded Classes） 和 MCU（Unloaded Classes）：若 MCL ↑ 且 MCU ≈ 0，说明类在堆积，使用率上涨不可逆
- 对比 Committed（已申请虚拟内存） 与 Used：committed 远大于 used，说明有“空洞”——类卸载后空间未归还，物理内存未释放，但使用率显示偏低，具误导性
典型失配场景举例
这些情况会让“类个数”和“使用率”看起来矛盾：
- 类个数稳定在 1 万，但使用率从 40% 涨到 90%：可能是某批动态类（如 AOP 切面）元数据异常膨胀，或常量池被反复写入重复字符串
- 类个数从 5 千猛增到 3 万，使用率只升 10%：说明新增类极轻量（如纯接口、空枚举），或大量类被快速加载又卸载（健康状态）
- 重启后类个数回落，但使用率不降反升：旧类加载器残留导致元空间 committed 内存无法重用，新类被迫分配在更高地址段，碎片化加剧
