java 类只有在满足特定条件时才会被卸载，即当加载该类的 classloader 实例本身不再被任何活动引用（成为垃圾回收的候选对象）时，其加载的所有类才会随之被卸载。这意味着类的生命周期与 classloader 的生命周期紧密绑定，只要 classloader 还活着，它加载的类就不会被卸载。
什么情况下 ClassLoader 会被垃圾回收？
ClassLoder 被垃圾回收的前提是它没有任何强引用。在 Java 中，ClassLoader 通常由 JVM 内部维护或作为应用的一部分存在。如果开发者自定义了一个 ClassLoader，并且没有将其存储在静态变量、线程局部变量或其他全局可访问的位置，那么当所有指向该 ClassLoader 的引用都被清除后，它就变成了垃圾。此时，JVM 的垃圾回收器（GC）会在下一次 GC 周期中回收这个 ClassLoader 实例。由于类对象（Class 实例）持有对 ClassLoader 的弱引用（WeakReference），一旦 ClassLoader 被回收，这些类也就失去了“根”，从而可以被卸载。
import java.net.URL;
import java.net.URLClassLoader;
public class ClassLoaderTest {
public static void main(String[] args) throws Exception {
// 创建一个临时的 URLClassLoader
// 假设有一个简单的类文件路径，这里用当前目录下的 classes
URL[] urls = new URL[]{new URL("file:./")};
URLClassLoader loader = new URLClassLoader(urls);
// 加载一个类，例如 String 或者自定义类
// 注意：为了演示卸载，最好加载一个自定义的、非系统类加载器加载的类
// 这里我们尝试加载一个假设存在的类 "MyClass"
try {
Class<?> clazz = loader.loadClass("MyClass");
System.out.println("Loaded class: " + clazz.getName());
System.out.println("ClassLoader: " + clazz.getClassLoader());
} catch (ClassNotFoundException e) {
System.out.println("Class not found, which is expected if MyClass doesn't exist.");
}
// 移除对 loader 的引用
loader = null;
// 建议触发 GC，虽然不保证立即执行
System.gc();
Thread.sleep(1000);
// 再次检查，理论上如果 GC 执行了，loader 及其加载的类应该被卸载
// 但由于 String 等核心类由 Bootstrap ClassLoader 加载，它们不会被卸载
// 所以这里主要看自定义 ClassLoader 是否被回收
System.out.println("After GC and nulling out loader reference.");
}
}
上述代码创建了一个临时的 URLClassLoader，并尝试加载一个类。随后将 loader 引用置为 null，并调用 System.gc() 建议进行垃圾回收。如果 URLClassLoader 没有其他引用，它将被回收，进而导致它加载的类被卸载。需要注意的是，像 java.lang.String 这样的类是由启动类加载器（Bootstrap ClassLoader）加载的，而启动类加载器是 JVM 的核心部分，永远不会被垃圾回收，因此这些类也不会被卸载。
你是 TypeScript 项目架构专家，专注于脚手架搭建生产就绪的 Node.js 和前端应用。生成包含现代工具链（pnpm、Vite、Next.js）、类型
立即学习“Java免费学习笔记（深入）”；
如何验证类是否被卸载？
要验证类是否被卸载，最直接的方法是监控 java.lang.ClassLoadingMXBean 或使用 JMX 工具。通过比较类加载前后的计数，可以观察到类数量的变化。此外，还可以使用 Class.getProtectionDomain().getCodeSource() 来获取类的来源，但这主要用于调试。更可靠的方式是通过自定义 ClassLoader 加载和卸载类，并观察内存中该类实例的存在与否。如果类被卸载，再次尝试加载同名类将会成功，因为 JVM 认为这是一个新的类加载过程。
import java.lang.management.ClassLoadingMXBean;
import java.lang.management.ManagementFactory;
public class ClassUnloadingVerification {
public static void main(String[] args) throws Exception {
ClassLoadingMXBean loadingBean = ManagementFactory.getClassLoadingMXBean();
int loadedClassesBefore = loadingBean.getTotalLoadedClassCount();
System.out.println("Loaded classes before: " + loadedClassesBefore);
// 模拟加载和卸载过程
// 这里需要实际执行加载和卸载操作，如前例所示
// 假设我们已经执行了加载和卸载
// 等待 GC 可能需要的延迟
Thread.sleep(2000);
int loadedClassesAfter = loadingBean.getTotalLoadedClassCount();
System.out.println("Loaded classes after: " + loadedClassesAfter);
// 如果类被卸载，loadedClassesAfter 应该小于 loadedClassesBefore
// 但请注意，JVM 可能会缓存一些类，导致计数不完全准确
// 最准确的方法是使用 JMX 或第三方库来监控类加载状态
}
}
通过比较 TotalLoadedClassCount 的变化，可以间接判断类是否被卸载。然而，由于 JVM 的优化和缓存机制，这种方法可能不够精确。更高级的验证方法包括使用 jmap 或 jcmd 等工具来检查堆内存中的类对象。如果类被卸载，这些工具将不会显示该类的相关信息。
基于程序中某个输入、条件或结果的具体问题
在实际应用中，类卸载的一个常见场景是热部署或插件系统。在这些场景中，开发者需要动态加载和卸载类，以避免内存泄漏和保持系统的灵活性。如果类没有被正确卸载，会导致 PermGen 空间（在 Java 8 及之前）或 Metaspace（在 Java 9 及之后）溢出，从而引发 OutOfMemoryError。因此，确保 ClassLoader 的正确管理和及时释放是防止此类问题的关键。此外，对于长期运行的应用，定期检查和清理不再使用的 ClassLoader 也是必要的维护工作。
