Compressed Class Space（CCS）是JVM启用压缩指针时额外划分的独立本地内存区域，专存Klass结构；它与Metaspace并列而非隶属，不参与GC，耗尽即OOM。
Compressed Class Space 是什么，它和 Metaspace 有什么区别
Compressed Class Space（CCS）不是 Metaspace 的子集，而是 JVM 启用压缩指针（-XX:+UseCompressedOops）时，**额外划分的一块本地内存区域**，专用于存储类的 Klass 结构（即 JVM 内部表示类的 C++ 对象，比如 Klass* 指针、vtable、itable 等）。它和 Metaspace 并列存在，但职责不同：Metaspace 存的是 Java 层元数据（常量池、方法字节码、注解等），CCS 存的是 JVM 运行时必需的低层类结构。
关键点在于：CCS 大小是**硬上限**，一旦耗尽，JVM 直接拒绝加载新类，抛出 java.lang.OutOfMemoryError: Compressed class space，且**不会触发 GC 回收**——它不参与任何垃圾回收机制。
为什么设置了 -XX:MaxMetaspaceSize 还会 OOM 在 CCS
因为两者完全独立。你可能给 Metaspace 划了 512MB，但 CCS 默认只有 1GB（64位 JVM 下典型值），而一个类在 CCS 中占用约 1–4KB（取决于字段数、方法数、泛型复杂度），当应用动态生成大量类（如 Lombok @Data、CGLIB 代理、GraalVM 动态编译、Quarkus native image 构建期反射注册），CCS 很快见底。
常见误判场景：
- 监控只看
jcmd <pid> VM.metaspace</pid>输出的Used和Classes loaded，却忽略 CCS 容量 - GC 日志里出现
Metadata GC Threshold，但实际触发的是 CCS 耗尽而非 Metaspace - 用
jmap -histo查类数量正常，却无法再加载新类——问题不在堆或 Metaspace，而在 CCS
如何查看和调整 Compressed Class Space 大小
默认大小由 JVM 自动计算（通常为 1GB），不可自动扩容。必须显式设置才能改变：
启动时加参数：-XX:CompressedClassSpaceSize=512m
注意三点：
- 该值必须是 2MB 的整数倍，且不能超过操作系统虚拟地址空间限制（Linux x86_64 下一般 ≤ 32GB）
- 它只在启用压缩指针时生效；若禁用（
-XX:-UseCompressedOops），CCS 不分配，Klass 结构直接混入 Metaspace 或其他本地内存区 - 修改后需重启 JVM，运行时不可调
验证是否生效：启动后执行 jinfo -flag CompressedClassSpaceSize <pid></pid>，输出应与设置一致。
排查 CCS 耗尽的真实信号有哪些
不要等 OOM 才行动。以下现象高度提示 CCS 接近瓶颈：
-
jstat -gc <pid></pid>显示CCSU（Compressed Class Space Used）持续 ≥90%，且CCSC（Capacity）恒定不变 - 应用日志中出现类加载失败，异常栈顶是
java.lang.OutOfMemoryError: Compressed class space，而不是Metaspace - 使用
jcmd <pid> VM.native_memory summary scale=MB</pid>，发现Class类别内存占用接近CompressedClassSpaceSize设置值，而Metaspace类别仍很空闲 - 频繁使用字节码生成库（如 Byte Buddy、Javassist）或框架（Spring AOP + CGLIB、Micrometer 的动态指标类）且类加载数飙升，但
Classes unloaded基本为 0
最隐蔽的坑是：CCS 耗尽时，JVM 不会记录 GC 日志，也不会触发任何 Metaspace 相关的阈值告警——它静默失败，只留下一个冷冰冰的 OOM。
