类卸载需同时满足三个条件：所有实例被回收、ClassLoader被回收、Class对象无任何引用；仅自定义类加载器加载的类才可能卸载，元空间内存下降是其成功标志。
方法区中类的卸载不是常规操作，只有在极少数场景下才可能发生，而且必须同时满足三个硬性条件。JVM不会主动卸载类，尤其是由系统类加载器（如Bootstrap、Extension、Application ClassLoader）加载的类，在整个虚拟机生命周期内基本不会被卸载。
类卸载的三个必要条件
一个类要被卸载，以下三点缺一不可：
- 该类的所有实例对象都已被垃圾回收，即堆中不再存在该类的任何活跃实例；
- 加载该类的 ClassLoader 实例本身也已被垃圾回收；
- 该类对应的 java.lang.Class 对象没有被任何地方引用，包括无法通过反射访问其方法或字段。
为什么这些条件很难同时满足
常见情况中，只要有一个条件不成立，卸载就无法进行：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 静态变量、单例对象、线程局部变量、缓存结构等，都可能长期持有类实例或 Class 对象的引用；
- 用户自定义 ClassLoader 若被上层对象（如 Web 容器中的 ServletContext）强引用，就不会被 GC，连带它加载的所有类也无法卸载；
- 即使所有实例都被回收，若 Class 对象被 Class.forName() 后缓存、或被 Spring 等框架保存在类型注册表中，卸载仍被阻断。
哪些场景真正需要并支持类卸载
只有具备动态类生命周期管理需求的系统才会启用该机制：
立即学习“Java免费学习笔记（深入）”；
- OSGi 框架：模块热部署依赖类卸载，每个 Bundle 使用独立 ClassLoader；
- Web 容器（如 Tomcat）：应用重启时，旧 WebAppClassLoader 被弃用并回收，其加载的类才可能被卸载；
- 基于字节码生成的框架（CGLib、Javassist、动态代理）频繁创建新类，若不卸载易引发 Metaspace OOM；
- 使用反射或 MethodHandle 触发类初始化后又长期不用，且无强引用残留时，才具备卸载基础。
如何控制类卸载行为
可通过 JVM 参数显式干预：
- -Xnoclassgc：禁止对类元数据执行 GC（包括卸载），默认关闭；
- -XX:+ClassUnloading：启用类卸载（HotSpot 默认开启，但仅对可卸载类生效）；
- -XX:+ClassUnloadingWithConcurrentMark：配合 CMS/G1 在并发标记阶段尝试卸载（高版本已整合）。
