双亲委派模型是JVM类加载的强制委托规则：先由父加载器尝试加载，失败后才由子加载器自行加载，确保核心类（如java.lang.String）由高信任级加载器加载，防止恶意替换，其本质实现在loadClass方法中。
双亲委派模型不是“有两个爹”，而是 JVM 类加载时强制向上委托、仅在父加载器失败后才自己动手的硬性规则。它直接决定了你的 java.lang.String 是不是真的来自 JDK，也决定了你写的 com.example.User 会不会被意外替换成恶意版本。
loadClass 方法里藏着的委派逻辑
所有自定义类加载器只要没重写 loadClass(String, boolean)，就默认走这个流程——它就是双亲委派的实现本体：
protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
synchronized (getClassLoadingLock(name)) {
Class c = findLoadedClass(name); // 先查缓存：已加载？→ 直接返回
if (c == null) {
try {
if (parent != null) {
c = parent.loadClass(name, false); // 委托给父加载器（递归）
} else {
c = findBootstrapClassOrNull(name); // 到顶：让C++写的Bootstrap试试
}
} catch (ClassNotFoundException e) {
// 父加载器说“找不到”，不慌，继续往下走
}
if (c == null) {
c = findClass(name); // 所有父都失败了 → 自己上：按路径找.class、读字节、defineClass
}
}
if (resolve) resolveClass(c);
return c;
}
}关键点：
-
findLoadedClass是第一道闸门：避免重复加载同一类（哪怕路径不同） - 委托链是单向的：
AppClassLoader → ExtClassLoader → BootstrapClassLoader，没有“回传”或“并行查找” -
findClass是唯一可安全重写的钩子；直接重写loadClass就等于手动绕过双亲委派——99% 的场景不该这么干
为什么 java.lang.Object 不可能被你覆盖
当你写 new Object()，JVM 要加载 java.lang.Object。此时：
立即学习“Java免费学习笔记（深入）”；
- 应用类加载器收到请求 → 委托给扩展类加载器
- 扩展类加载器 → 委托给启动类加载器
- 启动类加载器在
$JAVA_HOME/jre/lib/rt.jar（或 JDK 9+ 的modules）中找到并加载 - 后续所有类加载器再请求
java.lang.Object，都会命中缓存，绝不会落到你的 classpath 下去加载
这就是安全沙箱的底层保障：核心类永远由最高信任级别的加载器加载，你放一个同名类在 src/main/resources 里，它根本不会被考虑。
打破双亲委派的真实场景：Tomcat 和热加载
不是“能打破就该打破”，而是某些场景下，**必须打破**才能工作：
-
Web 容器隔离：Tomcat 为每个 WebApp 创建独立的
WebAppClassLoader，且它的父加载器是SharedClassLoader（不是AppClassLoader），并**重写了loadClass** ——优先用自己的路径加载，失败后再委派。否则多个应用共用的log4j版本会冲突 - 热部署/插件化：OSGi、Spring Boot DevTools、自研插件系统，都需要隔离类、允许卸载、支持多版本共存——这些都依赖打破委派后的“子优先”策略
-
加密类加载：你把
.class文件加密存储，必须自己解密字节码再defineClass，这时要继承ClassLoader并重写findClass，而不是动loadClass
ClassNotFoundException 和 ClassCastException 的根源
这两个异常，80% 都是双亲委派“太守规矩”或“被意外破坏”导致的：
-
ClassNotFoundException：你以为类在 classpath 里，但它被父加载器提前拦截（比如放在了lib/ext下却被 Bootstrap 加载失败），或者你用了自定义加载器但没正确设置parent字段，导致委托链断裂 -
ClassCastException：最典型的是org.springframework.context.ApplicationContext出现类型转换失败——本质是同一个类名，被两个不同类加载器（如 Tomcat 的WebAppClassLoader和CommonClassLoader）各自加载了一次，JVM 视为完全不同的类型
排查口诀：看类的 getClassLoader() 输出，比对是否一致；再看 Class.getProtectionDomain().getCodeSource()，确认来源路径。
双亲委派不是设计模式，是 JVM 的加载契约。理解它，不是为了背流程，而是当 ClassNotFoundException 突然出现、当热更新失效、当 Spring Bean 注入失败时，你能一眼看出问题不在代码，而在加载器之间的“信任链”断在哪一级。
