双亲委派是类加载的向上委托责任链机制：AppClassLoader先委托ExtClassLoader，再委托BootstrapClassLoader，仅当顶层失败才自救加载；其核心在loadClass()三步逻辑，且打破需重写loadClass()而非仅findClass()。
双亲委派不是“父母双亲”，而是“向上委托”的加载规则
双亲委派模型本质是一条类加载的「责任链」：当 AppClassLoader 收到加载 com.example.User 的请求时，它不会立刻去 classpath 查，而是先调用 parent.loadClass() 把请求甩给 ExtClassLoader；后者再甩给 BootstrapClassLoader；只有顶层加载器在 $JAVA_HOME/jre/lib/rt.jar 里找不到，请求才一级级退回，最终由应用类加载器自己调用 findClass() 去磁盘加载。
这个机制不是靠继承实现的——BootstrapClassLoader 是 C++ 实现、没有 Java 对象，ExtClassLoader 和 AppClassLoader 虽然继承自 URLClassLoader，但父子关系靠的是构造时传入的 parent 引用，不是 extends 关系。
为什么必须有这层委托？三个现实问题逼出来的
不走双亲委派，JVM 立刻出事：
-
安全崩塌：你写个
java.lang.String类，放在lib/下，若应用类加载器直接加载，就覆盖了 JVM 自带的String——所有equals()、hashCode()都可能被篡改，System、ClassLoader等核心类同理 -
ClassCastException 频发：两个不同加载器（比如 Tomcat 的两个 WebApp）各自加载了同一个
org.apache.commons.lang3.StringUtils，JVM 视为两个完全无关的类，哪怕字节码一模一样，强制转型就会抛异常 -
内存浪费+启动变慢：每个类加载器都重复加载
java.util.ArrayList，元空间里堆一堆相同类，GC 压力大，类初始化逻辑还可能执行多次
loadClass() 方法里藏着整个模型的开关
真正实现双亲委派的是 ClassLoader.loadClass(String, boolean) 的默认逻辑。它的关键分支就三步：
立即学习“Java免费学习笔记（深入）”；
- 先查缓存：
findLoadedClass(name)—— 已加载过直接返回，避免重复加载 - 再委派父类：
if (parent != null) parent.loadClass(name, false)；父为null时调用findBootstrapClassOrNull(name)（底层 native 方法） - 最后自救：
c == null且父全部失败 → 调用findClass(name)，这个方法是空的，**必须由子类重写**才能真正从文件/网络/数据库读取字节码
注意：findClass() 不做委派，只负责“找字节码”；而 defineClass() 才是把字节码转成 Class 对象的临门一脚。很多自定义加载器漏掉 defineClass()，结果字节码读到了却没变成类，报 NoClassDefFoundError。
打破双亲委派不是“破坏”，而是解决特定场景的刚需
Tomcat、OSGi、JDBC 驱动加载都在主动绕开它：
-
JDBC 4.0+：
ServiceLoader.load(Driver.class)用线程上下文类加载器（Thread.currentThread().getContextClassLoader()）去加载META-INF/services/java.sql.Driver，否则BootstrapClassLoader根本看不见你mysql-connector-java.jar里的实现类 -
Web 容器隔离：Tomcat 为每个 WebApp 创建独立的
WebAppClassLoader，并**重写loadClass()，先自己findClass()，失败再委派父类**——这样就能让两个 App 各自用不同版本的 Spring，互不干扰 - 热更新/插件化：每次重新加载插件时 new 一个新类加载器，旧类加载器连同它加载的所有类可被 GC，避免内存泄漏；但要注意静态字段、线程局部变量、JNI 资源等残留引用
真正容易踩的坑是：以为重写了 findClass() 就算打破委派，其实没动 loadClass()，请求照样先往上跑；或者打破后忘了清理类加载器引用，导致 PermGen / Metaspace 溢出。
