17370845950

双亲委派模型是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(nam
e, 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 里，它根本不会被考虑。

打破双亲委派的真实场景：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，就能绕过它——但别为了“炫技”而绕，绝大多数业务代码连自定义类加载器都不该碰。