类卸载是JVM在Full GC中被动完成的、以类加载器为单位的批量回收行为，需同时满足实例全回收、ClassLoader被回收、Class对象无引用三个条件；自定义类加载器是关键突破口，其动态加载的类才可能卸载；元空间内存下降是卸载成功的直接证据。
Java里类卸载不是主动触发的操作，而是JVM在满足严格条件后，于Full GC（或某些并发GC阶段）中被动完成的回收行为。它不针对单个类，而是以“类加载器”为单位批量清理——只有当某个类加载器被判定为可回收时，它所加载的所有类才可能一并卸载。
类卸载必须同时满足的三个硬性条件
缺一不可，且全部依赖垃圾回收器的可达性分析：
- 该类的所有实例对象都已被回收：堆中不能存在该类的任何直接或间接实例（包括子类实例）；
- 加载该类的ClassLoader实例已被回收：这个类加载器本身不能被任何GC Root（如静态变量、线程栈、JNI引用等）所引用；
- 该类对应的java.lang.Class对象未被任何地方引用：包括反射缓存、方法句柄、Lambda元工厂、甚至JMX监控或日志框架中隐式持有的Class引用。
为什么自定义类加载器是关键突破口
系统类加载器（如AppClassLoader）几乎永远存活，所以它加载的类基本不会卸载。真正能卸载的，几乎全是通过自定义ClassLoader动态加载的类——比如Web应用重部署、OSGi模块、Spring Boot DevTools热替换、CGLIB代理生成类等场景。
常见泄漏点：
立即学习“Java免费学习笔记（深入）”；
- 线程局部变量（ThreadLocal）中持有ClassLoader或Class引用；
- 静态集合（如ConcurrentHashMap）缓存了Class或其对象；
- 第三方库（如Logback、Jackson）内部注册了类监听器却未清理；
- 未关闭的URLClassLoader，其内部URLs数组和父加载器链形成强引用闭环。
元空间回收如何与类卸载联动
类卸载成功后，对应元空间中的数据块（Metachunk）才会被标记为空闲：
- 这些空闲Chunk先加入本地空闲列表，供后续同类加载器复用；
- 若整个内存块完全空闲，JVM会直接将其归还给操作系统（不是仅释放给JVM内部）；
- 因此Metaspace内存下降是类卸载成功的最直接证据，但反过来说，Metaspace没降 ≠ 没卸载——可能是Chunk被复用了，没还给OS。
怎么验证类是否真的卸载了
靠日志和工具组合判断，不能只看GC日志：
- 加参数：-XX:+TraceClassUnloading -XX:+PrintGCDetails，观察输出中是否有
Unloading class xxx； - 用jcmd
VM.metaspace 查看已卸载类数量（unloaded_class_count）和当前占用； - 配合jstat -gcmetacapacity
追踪metaspace容量变化趋势； - 注意：即使满足条件，也不保证“立刻卸载”，它依赖下一次合适的GC时机（尤其是需要Stop-The-World的Full GC）。
基本上就这些。类卸载机制本身不复杂，但容易忽略引用链的隐蔽性——一个弱小的静态日志器，可能让整个插件模块的类永久驻留。
