Java类加载器原理详解

本文深入剖析了Java类加载器的核心机制，系统讲解了Bootstrap、Extension和Application三类内置加载器的职责分工与父子委托关系，重点阐释了双亲委派模型的工作原理——即类加载时优先向上委托、失败后才自行加载，从而保障核心类安全与类的唯一性；同时揭示了按需加载（如new、静态访问、反射触发）、自定义ClassLoader的典型场景（热部署、插件隔离、动态字节码加载）及安全破委派的关键实践，并警示了常见陷阱，如上下文类加载器错配、数组类型加载器误区、内存泄漏风险以及模块化（JPMS）带来的演进变化，帮助开发者真正理解“何时该打破委派”以及“打破之后如何精准掌控类加载边界”。

ClassLoader 是 Java 中负责把 .class 文件（或字节码流）加载进 JVM 内存、并生成 Class 对象的机制。它不是“一次性加载所有类”，而是在真正用到某个类时才触发加载——比如调用 new、访问静态字段、反射 Class.forName() 等。

类加载器有哪几类？谁加载什么？

Java 内置三类核心加载器，构成一条委托链，但它们**不是继承关系，而是父子委托关系**：

• Bootstrap ClassLoader：C++ 实现，无父加载器，加载 $JAVA_HOME/jre/lib/rt.jar 里的核心类（如 java.lang.String、java.util.ArrayList）。你代码里拿不到它的引用（String.class.getClassLoader() 返回 null）。
• Extension ClassLoader：Java 实现，父为 Bootstrap，加载 $JAVA_HOME/jre/lib/ext/ 下的 JAR（如 javax.xml.* 相关类）。可通过 ClassLoader.getSystemClassLoader().getParent() 拿到它。
• Application ClassLoader（也叫 System ClassLoader）：Java 实现，父为 Extension，加载 -cp 或 CLASSPATH 指定路径下的类和 JAR。你写的主类（含 main 方法的类）基本都由它加载。

注意：Extension 和 Application 都是 URLClassLoader 的子类，能从文件系统或 URL 加载字节码；而 Bootstrap 不是 Java 类，不能被 Java 代码直接操作。

双亲委派模型到底怎么“委派”？

当一个 ClassLoader 被要求加载类（例如调用 loadClass("com.example.Foo")），它不会立刻自己去查文件，而是按以下顺序尝试：

• 先检查这个类是否已被当前加载器加载过（避免重复加载）；
• 若没加载过，且自己有父加载器 → 委托给父加载器的 loadClass()；
• 一直向上委托，直到 Bootstrap；
• 如果所有父加载器都返回 null（即找不到），才轮到当前加载器调用 findClass("com.example.Foo") 自行查找并定义（defineClass()）。

这就是「双亲委派」：不是“必须父类先加载”，而是“先让父类试试，不行再自己来”。它的价值在于：

• 防止核心类被用户自定义版本覆盖（比如你写个 java.lang.String，Bootstrap 已加载，就不会再走你自己的加载器）；
• 保证相同全限定名的类，在同一个 JVM 中只被一个加载器加载（避免 ClassCastException）。

什么时候要自定义 ClassLoader？怎么破双亲委派？

默认机制很安全，但某些场景必须绕开它：

• 热部署：Web 容器（如 Tomcat）需要单独卸载旧版本 WebApp 的类，再用新 ClassLoader 加载新版，否则老类还在内存里占着；
• 插件化/模块隔离：不同插件 jar 包里可能有同名类（如 org.slf4j.Logger），需各自加载互不干扰；
• 从非标准位置加载：比如从数据库 BLOB、加密 ZIP、HTTP URL 动态拉取字节码。

破委派的关键是重写 loadClass(String name, boolean resolve)，跳过 super.loadClass() 调用，直接调用 findClass(name)：

public class MyClassLoader extends ClassLoader {
    private final String baseDir;
public MyClassLoader(String baseDir) {
    this.baseDir = baseDir;
}

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // ? 不调用 super.loadClass() —— 打破双亲委派
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        byte[] bytes = loadByteCode(name); // 自己实现：读取 .class 字节
        c = defineClass(name, bytes, 0, bytes.length);
    }
    if (resolve) resolveClass(c);
    return c;
}

private byte[] loadByteCode(String name) {
    // 示例：从 baseDir + name.replace('.', '/') + ".class" 读取
    throw new UnsupportedOperationException();
}
}

⚠️ 注意：重写 loadClass() 是高危操作。一旦漏掉 findLoadedClass() 检查或 resolveClass() 调用，可能导致类加载失败或初始化异常。绝大多数情况只需重写 findClass() 并保留 super.loadClass() 委派逻辑。

容易被忽略的坑

类加载问题往往在运行时才暴露，且错误信息模糊：

• ClassNotFoundException 不一定代表类不存在，可能是当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()）和期望加载器不一致；
• 数组类型（如 String[]）没有自己的类加载器，它返回的是其元素类型（String.class.getClassLoader()）的加载器；
• ClassLoader 实例本身是对象，长期持有（比如缓存在静态 Map 中）会导致整个加载的类和其依赖无法 GC，引发内存泄漏；
• JDK 9+ 引入模块系统（JPMS）后，Extension 和 Application 加载器行为有调整，lib/ext 路径已废弃，改用 --module-path。

真正难的从来不是“怎么写一个加载器”，而是判断“该不该打破委派”、以及“打破之后，哪些类必须由谁加载”——这需要对整个应用的类依赖边界有清晰认知。

今天关于《Java类加载器原理详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！