JVM 类加载器如何保证核心类库不被覆盖？

结论先行：靠四道闸门层层拦截：双亲委派让加载请求先交给启动类加载器（bootstrap loader），核心类在它那里就命中返回，用户类根本没有机会定义同名类；包名保护在 ClassLoader.preDefineClass 里硬性拒绝任何加载器定义 java.* 开头的类；启动类加载器不可见，它由 C++ 实现、在 Java 层拿不到引用，无法被替换；模块封装（JDK 9+）进一步限制对 JDK 内部包的访问。四道闸门任意一道生效，就足以阻止「伪造 java.lang.String」。

一、四道闸门

用户代码: new MyLoader().loadClass("java.lang.String")
      │
      ▼
MyLoader.loadClass ──委派──→ AppClassLoader ──委派──→ Platform ──委派──→ Bootstrap
                                                                          │
                                                   命中：返回 JDK 的 String
      │
      └─ 若 Bootstrap 找不到（理论上不会），MyLoader 才 findClass
            └─ defineClass("java.lang.String") → preDefineClass 抛
               SecurityException: Prohibited package name: java.lang

二、亲手验证一次

import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;

public class HijackDemo extends ClassLoader {
    private final Path classFile;

    public HijackDemo(Path classFile) {
        super(null);                     // parent=null 也无法绕过包名检查
        this.classFile = classFile;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] bytes = Files.readAllBytes(classFile);   // 自己伪造的 java.lang.String.class
            return defineClass(name, bytes, 0, bytes.length);
        } catch (IOException e) {
            throw new ClassNotFoundException(name, e);
        }
    }

    public static void main(String[] args) throws Exception {
        HijackDemo loader = new HijackDemo(Path.of("fake/java/lang/String.class"));
        Class<?> c = loader.loadClass("java.lang.String");    // 委派给 bootstrap，直接命中真类
        System.out.println(c.getClassLoader());                // null（bootstrap 加载）

        loader.findClass("java.lang.String");                  // 绕开委派直接定义
    }
}
// 输出：
// null
// Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang

注意两点：loadClass 走委派后拿到的是真类，getClassLoader() 为 null 正是 bootstrap 的标志；而 findClass 直接调用时，defineClass 的包名检查会立刻拒绝。

三、历史上的「合法」覆盖

所以「核心类库不可被覆盖」并不是绝对的密码学保证，而是「默认路径全部封死，只剩需要显式授权的诊断入口」。JDK 自己升级、打补丁用的就是 --patch-module 这类机制。

四、常见追问

小结

核心类库安全靠「委派优先 + 包名白名单 + 引导加载器不可触达 + 模块封装」四层。答题时能指出 preDefineClass 和 Prohibited package name 这条硬拦截，比只说「双亲委派」更有说服力。