Java 类加载器与垃圾回收的关系分析

在Ja va的世界里，类加载器和垃圾回收器，一个是内存的“入口守卫”，一个是“出口清道夫”。你可能觉得它们是两条平行线，各干各的。但聊深了你就会发现，这两者之间存在着一种看似隐蔽，实则足以引发系统性风险的“隐性耦合”。

简单来说，类加载器决定了对象生命周期的起点，而GC决定了它的终点。更深一层，一个类本身能否被JVM“请出”元空间，完全取决于GC是否已经清扫干净所有对该类及其类加载器的引用。这才是问题的关键所在。

类加载器与GC：从入口到守门人的博弈

类加载器负责把.class字节码搬进方法区（JDK 8之后是元空间），并顺手在堆里生成那个我们熟悉的ja va.lang.Class对象。这个Class对象本身，就是个普普通通的堆内对象，受GC管理。那么，JVM在什么条件下才会认为一个类可以“卸载”呢？必须同时满足以下三个条件：

• 该类的所有实例，都已被GC回收。
• 加载该类的那个 ClassLoader实例本身，已经不可达（也就是它自己也得被GC回收掉）。
• 这个Class对象，在任何地方（静态字段、线程栈、JNI引用等）都没有了任何引用。

三个条件，缺一不可。其中第二条尤其值得注意：只要类加载器还活着，它加载的所有类就都别想走，哪怕这些类早已无人问津。

双亲委派模型：核心类永生的“护身符”

我们熟悉的Bootstrap、Extension、Application这三个类加载器，它们的生命周期和JVM一样长。JVM内部会一直持有对它们的强引用。这意味着，它们加载的那些核心类（比如ja va.lang.Object），因为永远有活跃的引用链，GC永远不会认为它们是“不可达”的。所以，这些类根本就不会触发卸载逻辑。

这个设计看似是GC的限制，其实是架构上的约束——类加载器机制本身，就对GC的行为画了一条不可逾越的红线，保护了核心类库的永生。

自定义类加载器：热部署场景下的“元空间泄漏”元凶

在热部署、插件化、OSGi这类场景下，我们经常一挥手就创建一个临时的类加载器来加载业务模块。这时候，模块卸载成功与否，完全取决于GC能不能回收掉这个类加载器。问题也常常出在这里：

• 如果代码里某个地方意外地保留了对ClassLoader的静态引用（比如存到一个单例缓存的Map里，或者被ThreadLocal不经意地持有了），那这个加载器和它加载的所有类都会永远驻留，直接导致元空间泄漏。
• 反射调用后，如果没有及时清理掉对Method、Field的软引用，也可能延长Class对象的存活时间。
• 线程上下文类加载器（ContextClassLoader）如果被长期运行的线程（比如线程池里的线程）持有了，也会成为卸载的障碍。

这类问题，表象通常是元空间持续膨胀，Full GC频繁但内存就是释放不了。追根溯源，问题往往不在对象本身，而在于类加载器的引用链条没断开。

如何验证？GC日志与工具是“照妖镜”

想要验证类卸载是否成功，可以试试这几个方法：

• 启动参数里加上 -XX:+TraceClassUnloading，在GC日志里搜索“Unloading class xxx”，看到这个记录就说明类卸载成功了。
• 用 jcmd VM.native_memory summary 或 jstat -gcmetacapacity 来观察元空间的使用趋势，以此判断类加载器是否真正释放了内存。

最后需要记住的是，类的卸载是异步的，且非强制。JVM只在它认为合适的时机才会执行，不会因为你感觉某个类没用了，它就立刻动手。理解这一点，对排查相关问题会有很大帮助。