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

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

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学习网公众号，带你了解更多关于的知识点！