双亲委派模型是JVM类加载的强制向上委托规则：先查缓存，再递归委托父加载器，仅父失败后才调用findClass自行加载，确保核心类如java.lang.Object由Bootstrap加载，保障安全沙箱。
双亲委派模型不是“有两个爹”，而是 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_HOME/jre/lib/rt.jar（或 JDK 9+ 的 modules）中找到并加载 - 后续所有类加载器再请求
java.lang.Object，都会命中缓存，绝不会落到你的classpath下去加载
这就是安全沙箱的底层保障：核心类永远由最高信任级别的加载器加载，你放一个同名类在 src/main/resources 里，它根本不会被考虑。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
打破双亲委派的真实场景：Tomcat 和热加载
Web 容器如 Tomcat 必须打破双亲委派，否则无法隔离不同 Web 应用的类（比如两个 app 都用了不同版本的 log4j）。它的做法是：
- 自定义
WebAppClassLoader，重写loadClass：先自己尝试加载WEB-INF/classes和WEB-INF/lib下的类 - 仅对
java.*、javax.*、sun.*等包才向上委派 - 热部署时，直接丢弃旧的
WebAppClassLoader实例，新建一个，从而加载新字节码
注意：这种打破是有代价的——你不能在 WEB-INF/lib 里放一个 java.lang.String，但也不能指望它被 Bootstrap 加载后还能被你替换；Tomcat 的隔离粒度是应用级，不是类级。
真正容易被忽略的是：双亲委派不是 JVM 规范强制要求的“必须行为”，而是 JDK 提供的 ClassLoader 默认实现。只要你继承 ClassLoader 并重写 loadClass，就能绕过它——但别为了“炫技”而绕，绝大多数业务代码连自定义类加载器都不该碰。
