当前位置：首页 > 文章列表 > 文章 > java教程 > JVM压力测试：元空间与CompressedClassSpace关系解析

JVM压力测试：元空间与CompressedClassSpace关系解析

2026-05-08 17:57:59 0浏览收藏

本文深入剖析了JVM中容易被忽视却极为关键的Compressed Class Space（压缩类空间）机制，揭示其与Metaspace的本质区别：它并非元空间的一部分，而是专用于存储压缩Klass指针的固定大小（默认1G）、不可动态扩容的独立内存区域；当出现“java.lang.OutOfMemoryError: Compressed class space”时，往往不是类元数据过多，而是类加载器泄漏或动态代理滥用导致Klass指针持续堆积、无法卸载的真实警报——这一错误实为类生命周期失控的早期信号，比普通Metaspace OOM更敏锐、更具诊断价值，值得所有使用Spring AOP、CGLIB或热部署的微服务开发者高度重视。

如何通过 JVM 的 Compressed Class Space 限制理解在大规模动态代理生成场景下元空间的分配压力

Compressed Class Space 是什么，为什么它会单独报错

当看到 java.lang.OutOfMemoryError: Compressed class space，说明不是元空间整体耗尽，而是专门用于存储压缩类指针的那块固定内存满了。它和 Metaspace 是两个独立区域：前者只存 Klass 结构体中的压缩指针（默认 1G），后者存完整的类元数据（如方法字节码、常量池等）。两者都位于本地内存，但分配策略不同——CompressedClassSpaceSize 一旦设定就不可动态扩容，而 Metaspace 可以按需增长（只要没超 MaxMetaspaceSize）。

该错误常见于大量使用 CGLIB、Byte Buddy 或 Spring AOP 的微服务，尤其在开启 -XX:+UseCompressedClassPointers（JDK8u60+ 默认启用）且堆
每个动态生成的类都会在 Compressed Class Space 中占用一个 Klass 指针槽位，哪怕类体很小
即使你把 MaxMetaspaceSize 设得很大，只要这个 1G 的压缩空间被填满，照样 OOM

如何确认是不是 Compressed Class Space 真的不够用

不能只看 GC 日志里 Metaspace 行；要查 CCSC（Compressed Class Space Capacity）和 CCSU（Compressed Class Space Used）指标。用 jstat -gc 输出中这两列持续逼近上限，就是铁证。

jstat -gc 输出示例：CCSMN CCSMX CCSC YGC FGC → 0.0 1048576.0 1048320.0 15 3，其中 CCSC=1048320.0 表示已用 1024MB，接近默认 1G 上限
启动时加 -XX:+PrintGCDetails，日志中若出现 [Metaspace: ...][Compressed Class Space: 1048576K->1048576K(1048576K)]，且第二组数字始终不降，说明无法回收
jcmd VM.metaspace 会明确列出 CompressedClassSpace 的 committed/used/max 值，比 jstat 更直观

调大 CompressedClassSpaceSize 的实际效果与边界

增大这个值能缓解问题，但不是万能解法。它本质是给 Klass 指针预留更多连续虚拟地址空间，而非真正“节省内存”。盲目调大会浪费虚拟内存，甚至在某些容器环境触发 cgroup 内存限制。

设置方式：-XX:CompressedClassSpaceSize=2g（注意单位必须是 g 或 m，不能写 2048m）
最大允许值为 3G，超过会启动失败并报错：Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit.
如果堆 > 32GB，UseCompressedClassPointers 自动失效，此时该参数无效，所有 Klass 指针回归 64 位，不再走压缩空间——但元空间整体压力反而更大
调大后务必配合监控：观察 jstat -gc 中 CCSC 是否稳定、FGC 次数是否下降；若仍频繁 Full GC，说明根本问题是类加载器泄漏，不是空间不够

真正压垮 Compressed Class Space 的，往往是类加载器设计缺陷

Compressed Class Space 占用高，表象是类多，根因常是类加载器没被回收。每个自定义类加载器都会独占一块压缩空间配额，哪怕它只加载了一个代理类。

Spring Boot DevTools 默认启用热重载，每次修改都会创建新 RestartClassLoader，旧的未被 GC → 元数据 + 压缩指针双倍堆积
Tomcat 部署多个 WAR 包时，每个应用有独立 WebAppClassLoader，若未正确 stop，其加载的所有动态类（包括 CGLIB 生成的）永远卡在压缩空间里
排查线索：-XX:+TraceClassUnloading 启动后看日志是否几乎不输出卸载记录；jmap -clstats 查看存活的类加载器数量是否随部署次数线性增长

压缩类空间不是黑盒缓存，它是一块有硬边界的虚拟内存池。它的压力信号（Compressed class space OOM）比普通 Metaspace OOM 更早暴露类加载器生命周期失控的问题——这点最容易被忽略。

到这里，我们也就讲完了《JVM压力测试：元空间与CompressedClassSpace关系解析》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！