Java内置三类核心类加载器：Bootstrap（C++实现，加载rt.jar）、Extension（加载lib/ext）、Application（加载-classpath）；它们构成父子委托链，遵循双亲委派模型——先委托父加载器，失败后才自行加载，以保障核心类安全与类唯一性。
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 Classzuojiankuohaophpcn?youjiankuohaophpcn loadClass(String name, boolean resolve) throws ClassNotFoundException {
// ? 不调用 super.loadClass() —— 打破双亲委派
Classzuojiankuohaophpcn?youjiankuohaophpcn 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。
真正难的从来不是“怎么写一个加载器”，而是判断“该不该打破委派”、以及“打破之后，哪些类必须由谁加载”——这需要对整个应用的类依赖边界有清晰认知。
