Java双亲委派模型：保障类加载安全与唯一性

Java双亲委派模型并非继承关系，而是一条由Bootstrap、Ext和AppClassLoader通过parent字段构成的向上委托链，其核心价值在于保障类加载的安全性与唯一性——它确保如java.lang.String这样的核心类永远由启动类加载器加载，杜绝恶意替换；同时避免同一类被不同加载器重复加载导致ClassCastException等运行时错误。自定义类加载器必须显式维护委托逻辑（如调用super.loadClass），否则极易破坏机制引发故障；虽可在热部署、模块隔离等特殊场景下“打破”委派，但需谨慎设计包过滤策略，因为真正的安全防线不仅在于委派顺序，更在于JVM对核心包的硬性保护与字节码验证机制。

双亲委派不是继承关系，而是“委托链”

很多人一看到“双亲”就下意识以为是 Java 类的 extends 关系，其实完全不是——BootstrapClassLoader、ExtClassLoader、AppClassLoader 之间没有父子类继承，而是通过组合（parent 字段）构成一条向上的委托链。你自定义类加载器时，如果直接 new 一个 ClassLoader() 而不指定 parent，它的 parent 默认是 Thread.currentThread().getContextClassLoader()，而不是系统默认的 AppClassLoader，这点极易踩坑。

• 检查委托链是否生效：调用 myLoader.getParent() 看返回值，别假设它自动连上了 AppClassLoader
• 重写 loadClass(String name) 时，必须显式调用 super.loadClass(name) 或手动调用 parent.loadClass(name)，否则双亲委派就断了
• 不要重写 findClass(String name) 来做委托逻辑——它只负责“自己找字节码”，委托动作必须在 loadClass 中完成

为什么 java.lang.String 永远不会被你写的同名类替换

这不是 JVM 的“魔法”，而是双亲委派的刚性执行结果：当你调用 MyClassLoader.loadClass("java.lang.String")，请求会一路向上委派到 BootstrapClassLoader；它从 $JAVA_HOME/jre/lib/rt.jar（或 modules/java.base）中成功加载了真正的 String 类，并返回 Class 对象；你的类加载器根本没机会读取你项目里那个 java/lang/String.class 文件。

• 哪怕你把恶意 String.class 放进 -Xbootclasspath/a:，启动类加载器仍可能优先加载原生版本（取决于 JDK 版本和模块系统行为）
• 如果你用反射强行尝试 defineClass("java.lang.String", bytes, 0, bytes.length)，JVM 会在验证阶段抛出 SecurityException: Prohibited package name: java.lang
• 真正能绕过这层防护的，只有修改 JVM 启动参数（如 --patch-module）或使用 Instrumentation + agent，普通应用代码做不到

ClassCastException 的真实来源：同一个类被两个类加载器加载

这是双亲委派失效后最典型的运行时错误。比如 Web 容器中，两个 WAR 包都含 com.fasterxml.jackson.databind.ObjectMapper，但各自用独立的 WebAppClassLoader 加载，就会导致：A 应用传过来的 ObjectMapper 实例，在 B 应用里无法强转成同一类型——因为它们的 ClassLoader 不同，JVM 视为两个无关类。

• 排查方法：打印出错类的 obj.getClass().getClassLoader() 和目标类型的 TargetClass.class.getClassLoader()，对比是否一致
• 常见诱因：SPI 服务发现（如 ServiceLoader.load(X.class)）默认用线程上下文类加载器（TCCL），而该加载器可能和当前类的加载器不一致
• 修复方向：显式传入期望的类加载器，例如 ServiceLoader.load(X.class, MyClassLoader.class.getClassLoader())

想打破双亲委派？先确认你真需要它

绝大多数业务场景不该打破双亲委派。所谓“打破”，本质就是重写 loadClass 方法，把“先委派父类”改成“先自己找”。典型需求只有三类：热部署容器（如 Tomcat）、模块化框架（如 OSGi/Pandora）、或隔离不同版本的三方库（如同时用 log4j 1.x 和 2.x）。

• Tomcat 的 WebAppClassLoader 是反双亲委派的：先查 WEB-INF/classes 和 WEB-INF/lib，找不到才委派给父加载器
• 但注意：它对 java.*、javax.*、org.apache.catalina.* 等包做了白名单拦截，强制走父加载器，防止容器自身被污染
• 自己实现时，务必加包名过滤逻辑，否则容易引发 NoClassDefFoundError 或核心类冲突

双亲委派的边界感很关键：它不控制“哪些类能被加载”，只控制“谁来加载”。真正决定安全性的，是类加载器自身的加载路径、字节码校验机制，以及 JVM 对 java.* 包的硬性保护。试图靠“绕过委派”来加载核心类，基本都会在验证阶段失败。

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