双亲委派模型如何保护核心类不被篡改

双亲委派模型并非依赖运行时权限检查或代码拦截来守护Java核心类，而是从JVM启动之初就通过加载路径锁定、委托顺序强制和类唯一性约束三重机制构筑坚实防线：Bootstrap ClassLoader独占java.*等系统类的定义权，所有其他类加载器必须无条件向上委托，任何绕过委派的尝试（如自定义加载java.lang.String）都会在defineClass阶段触发JVM内置的SecurityException；即便强行加载同名类，也会因加载器命名空间隔离而与原生类完全不兼容，导致ClassCastException；而AppClassLoader等仅作转发、绝不参与定义，彻底封死篡改入口——这是一套根植于JVM架构底层、不可绕过的安全契约。

双亲委派模型不是靠“拦截代码”或“权限检查”来防篡改，而是通过加载路径锁定、委托顺序强制和类唯一性约束三层机制，在 JVM 启动阶段就切断篡改可能。

启动类加载器独占 java.* 类的定义权

所有以 java.lang.、java.util.、javax.* 等开头的类，JVM 规定只能由 Bootstrap ClassLoader 加载。它不读取 classpath，只信任 JAVA_HOME/jre/lib/rt.jar（或 modules）等硬编码路径。即使你把自定义的 java.lang.String.class 放进项目里，应用类加载器收到请求后第一反应是向上委托，根本不会去扫描你的本地目录。

绕过委派会触发 JVM 级拒绝

如果重写 loadClass() 跳过 super.loadClass()，试图自己加载 java.lang.String，JVM 在 defineClass() 阶段会直接抛出 SecurityException，而不是返回错误或静默失败。这不是类加载器能控制的逻辑，而是 JVM 内置的安全校验——只要检测到非 Bootstrap 加载器尝试定义 java.* 包下的类，立即终止。

同名 ≠ 同类：加载器命名空间天然隔离

Java 中两个类是否“是同一个类”，取决于全限定名 + 加载器实例。哪怕你用非法手段绕过所有限制，成功用自定义加载器加载了一个 java.lang.String，它在运行时也和 JVM 自带的 String 完全不兼容：

• new String() 创建的对象类型是 Bootstrap 加载的 String
• 你加载的同名类属于另一个命名空间，无法赋值给 String s 变量
• 调用 equals() 或转型时会报 ClassCastException

系统加载器只做转发，不参与定义

AppClassLoader 和 ExtClassLoader 对 java.* 类的处理逻辑非常干净：收到请求 → 立即调用 findSystemClass(name) → 交由 Bootstrap 处理 → 返回结果或抛异常。它们不查找本地文件、不读取字节码、不调用 defineClass()。这个方法是 JVM 提供的唯一合法入口，且对非系统包返回 null，对系统包失败则直接中断，不留注入缝隙。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《双亲委派模型如何保护核心类不被篡改》文章吧，也可关注golang学习网公众号了解相关技术文章。