Java双亲委派模型详解与类加载安全机制

哈喽！今天心血来潮给大家带来了《Java双亲委派模型是什么？类加载安全机制详解》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

双亲委派模型是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_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 注入失败时，你能一眼看出问题不在代码，而在加载器之间的“信任链”断在哪一级。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于文章的相关知识，也可关注golang学习网公众号。