Compressed Class Space 是JVM中专用于存储压缩Klass指针的固定大小内存区域（默认1G），与Metaspace分离；其OOM表明该区域耗尽，常见于动态代理频繁、类加载器泄漏场景。
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 <pid> 输出中这两列持续逼近上限，就是铁证。
-
jstat -gc <pid>输出示例：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 <pid> 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 <pid>中CCSC是否稳定、FGC次数是否下降；若仍频繁 Full GC，说明根本问题是类加载器泄漏，不是空间不够
真正压垮 Compressed Class Space 的，往往是类加载器设计缺陷
Compressed Class Space 占用高，表象是类多，根因常是类加载器没被回收。每个自定义类加载器都会独占一块压缩空间配额，哪怕它只加载了一个代理类。
- Spring Boot DevTools 默认启用热重载，每次修改都会创建新
RestartClassLoader，旧的未被 GC → 元数据 + 压缩指针双倍堆积 - Tomcat 部署多个 WAR 包时，每个应用有独立
WebAppClassLoader，若未正确 stop，其加载的所有动态类（包括 CGLIB 生成的）永远卡在压缩空间里 - 排查线索：
-XX:+TraceClassUnloading启动后看日志是否几乎不输出卸载记录；jmap -clstats <pid>查看存活的类加载器数量是否随部署次数线性增长
压缩类空间不是黑盒缓存，它是一块有硬边界的虚拟内存池。它的压力信号（Compressed class space OOM）比普通 Metaspace OOM 更早暴露类加载器生命周期失控的问题——这点最容易被忽略。
