Compressed Class Space 是 JVM 启用压缩指针时独立划分的固定大小内存区域（默认1G），专存 Klass 结构，不参与 GC；耗尽即抛 OutOfMemoryError: Compressed class space，与 Metaspace 是否充足无关。
排查 Compressed Class Space 满引发的 Metaspace OOM，核心是确认“不是普通元空间耗尽，而是压缩类空间（Compressed Class Space）先触顶”，因为它是 Metaspace 中独立管理的一块区域，专用于存储 Klass 结构（JVM 内部表示类的元数据），默认大小固定、不可自动扩容。一旦它被占满，即使 Metaspace 整体还有余量，也会直接抛出 OutOfMemoryError: Metaspace。
确认是否真为 Compressed Class Space 耗尽
不能只看 MU（Metaspace 已使用量），必须单独观察压缩类空间指标：
- 用
jstat -gc <pid>查看输出中的CCSU（Compressed Class Space Used）、CCSMX（Compressed Class Space Max）和CCSC（Compressed Class Space Capacity） - 若
CCSU / CCSMX ≈ 100%且持续不下降，而MC（Metaspace 当前容量）远未达MaxMetaspaceSize，就基本锁定是压缩类空间瓶颈 - GC 日志中出现
Metadata GC Threshold同时伴随Class Histogram显示大量Klass实例，也是佐证
检查动态类生成是否失控
压缩类空间主要被 Klass 对象占用，而每个动态生成的类（如 CGLIB 代理、ASM 织入、Javassist 修改类）都会创建新 Klass。重点查：
- 是否禁用了代理缓存：例如 CGLIB 的
Enhancer.setUseCache(false)或 Spring AOP 未启用@EnableCaching配合代理复用 - 是否在循环或高频路径中调用字节码工具：比如每次 HTTP 请求都
new Enhancer().create()，而非复用单例 Enhancer 或预生成 - 是否使用了热重载框架（如 Spring Boot DevTools、JRebel）但未配置类卸载策略，导致旧 Klass 积压不释放
验证类卸载是否真正发生
压缩类空间能否回收，取决于对应类能否被卸载——这要求类加载器被回收，且该加载器加载的所有类无任何强引用。
- 开启
-XX:+PrintClassHistogramBeforeFullGC -XX:+PrintClassHistogramAfterFullGC，对比 Full GC 前后 Klass 数量变化；若几乎不变，说明类没卸载 - 用
jcmd <pid> VM.class_hierarchy -all查看活跃类加载器数量，若随时间持续增长，大概率存在类加载器泄漏 - 检查自定义类加载器是否持有静态引用（如缓存 Map、线程局部变量 TLV）、是否未重写
finalize()或未显式调用close()
针对性调优与规避
压缩类空间大小由 -XX:CompressedClassSpaceSize 控制，默认值通常为 1G（64 位 JVM 启用压缩指针时）。但盲目调大治标不治本，应结合场景处理：
- 对已知稳定代理类型，改用接口代理（JDK Proxy）替代 CGLIB，减少 Klass 创建量
- 设置合理上限：
-XX:CompressedClassSpaceSize=512m+-XX:MaxMetaspaceSize=1g，避免无节制占用本地内存 - 强制启用类卸载：
-XX:+CMSClassUnloadingEnabled（CMS）或-XX:+UseG1GC -XX:+G1UseAdaptiveIHOP -XX:+G1UseAdaptiveIHOP（G1）配合-XX:+UseStringDeduplication - 生产环境禁用开发向功能：关闭 DevTools、移除 JRebel Agent、禁用运行时字节码增强（如某些监控 SDK 的 trace 插件）
