双亲委派模型是类加载的强制约定：类加载器收到请求后先委派父加载器，直至bootstrapclassloader；父无法加载时子才自行加载，核心目的是保障核心类隔离与一致性。
双亲委派模型到底是什么，不是“先让父类加载器试一遍”那么简单
双亲委派不是一句口号，而是一套强制约定：当一个 ClassLoader 收到类加载请求时，它不会自己先去加载，而是把请求委派给 parent（父加载器），层层向上，直到到达 BootstrapClassLoader；只有父加载器无法完成加载（比如在它的路径下找不到该类），子加载器才尝试自己加载。
这个机制的核心目的不是“复用”，而是**隔离与一致性**：确保 java.lang.String 这种核心类永远由启动类加载器加载，避免被用户自定义的同名类替换，防止运行时冲突和安全漏洞。
注意：BootstrapClassLoader 是 C++ 实现、没有 Java 对象引用，所以它的 parent 是 null；ExtClassLoader 的 parent 是 null（不是 Bootstrap），AppClassLoader 的 parent 才是 ExtClassLoader。别记反了。
为什么 Thread.getContextClassLoader() 会破坏双亲委派
这是最常见也最容易被忽略的破坏方式。JDBC 就是典型：DriverManager 是由启动类加载器加载的（在 rt.jar 中），但它需要加载用户提供的 com.mysql.cj.jdbc.Driver —— 这个类显然不在 BootstrapClassLoader 的路径里。
立即学习“Java免费学习笔记（深入）”；
解决办法是：DriverManager 内部不直接用 Class.forName()，而是调用 Thread.currentThread().getContextClassLoader().loadClass()。这个上下文类加载器默认是 AppClassLoader，于是绕过了双亲委派链，实现了“父加载器请求子加载器干活”的逆向委托。
- 这种破坏是**有意为之且必要**的，属于“服务提供者接口（SPI）场景”
- 但风险在于：如果线程上下文类加载器被错误设置（比如设成了自定义的、范围过窄的加载器），就会抛
ClassNotFoundException - Web 容器（如 Tomcat）也大量依赖此机制实现应用间类隔离
自定义 ClassLoader 重写 loadClass() 就算破坏双亲委派吗
不一定。关键看你怎么重写。
标准写法是这样的：
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, resolve); // ✅ 委派给父
else c = findBootstrapClassOrNull(name); // ✅ 委派给 Bootstrap
} catch (ClassNotFoundException e) {
c = findClass(name); // ❌ 父失败后才自己找
}
}
if (resolve) resolveClass(c);
return c;
}
}
如果你删掉委派逻辑，直接在 loadClass() 里调用 findClass()，那就彻底破坏了；但更常见的“破坏”其实是**重写 findClass() + 指定不同资源路径**，这不算违规——双亲委派只管“谁来触发加载”，不管“从哪读字节码”。
- 真正危险的是：在
findClass()里又 new 了一个别的ClassLoader去加载，造成加载器树混乱 - 热部署、OSGi、模块化（JPMS）都依赖对委派逻辑的精细控制，不是简单“绕过”就行
- JDK 9+ 的模块系统引入了
ModuleLayer和Configuration，双亲委派在模块边界上已不完全适用
tomcat/webapps/xxx/WEB-INF/lib 下的类为什么不会被 AppClassLoader 加载
因为 Tomcat **没用默认的双亲委派顺序**。它为每个 Web 应用创建独立的 WebAppClassLoader，其委派策略是：先尝试自己加载（即查 WEB-INF/classes 和 WEB-INF/lib），失败后再委派给父加载器（SharedClassLoader → CommonClassLoader → AppClassLoader）。
这就是“反双亲委派”（或称“本地优先”）：确保应用自己的 spring-core-5.3.30.jar 不会被容器共享的 spring-core-4.2.9.jar 覆盖。
- 这种破坏必须配合严格的类加载器隔离（比如不同应用的
WebAppClassLoader互不可见） - 若应用用了
Thread.currentThread().setContextClassLoader()却没恢复，可能引发ClassCastException（同一类被两个不同加载器加载，类型不兼容） - 排查类加载问题时，别只看
ClassLoader.getSystemClassLoader()，要打日志输出实际执行加载的getClass().getClassLoader()
ClassLoader，就得自己保证 java.* 类不被污染，也得处理好资源查找、卸载、内存泄漏这些隐性成本。 
