如何从类加载器源码理解双亲委派模型的向上委托逻辑-java教程-PHP中文网

双亲委派机制的核心实现在ClassLoader.loadClass()方法中：先调findLoadedClass查缓存，再委托parent.loadClass向上委派，父加载器无法加载时才调用findClass自行加载。

如何从类加载器源码理解双亲委派模型的向上委托逻辑

loadClass 方法就是双亲委派的执行体

双亲委派不是抽象概念，它就实打实地写在 ClassLoader.loadClass(String name, boolean resolve) 的源码里。这个方法默认实现就是整个模型的骨架：先查缓存、再委派父加载器、父不行才调用 findClass() 自己加载。

关键逻辑是向上委托链：如果当前加载器的 parent 不为 null，就直接调用 parent.loadClass(name, resolve) —— 注意，这不是继承调用，而是组合关系下的显式委托。启动类加载器（BootstrapClassLoader）没有 Java 对应对象，所以它的 parent 是 null，递归在此终止。

常见误判点：

以为重写了 findClass() 就打破了双亲委派 —— 错，只要没动 loadClass()，委托链依然完整
看到 String.class.getClassLoader() 返回 null 就认为“没加载器” —— 实际是 Bootstrap 加载的，Java 层不可见，null 是设计使然
在自定义加载器中直接 new 一个 Class 对象返回 —— 这绕过了验证和链接阶段，JVM 会抛 SecurityException 或直接拒绝

findLoadedClass 是第一道安全闸门

loadClass() 开头必调 findLoadedClass(name)，这是 JVM 内部维护的已加载类缓存（基于类全名 + 加载器实例双重判定）。它防止同一个类被同一加载器重复定义，也杜绝了“父加载器没加载，子加载器又加载一遍”的冲突。

这个缓存是加载器实例私有的，不同加载器之间互不共享。这也是为什么 Tomcat 用多个 WebAppClassLoader 隔离应用 —— 即便两个应用都含 com.fasterxml.jackson.databind.ObjectMapper，只要加载器不同，它们在 JVM 中就是两个完全无关的类，不会互相干扰。

注意：findLoadedClass 查不到时，才进入委托流程；它查到了，就直接返回，不走任何父加载器。

为什么不能直接重写 loadClass 来跳过委托

手动重写 loadClass() 并跳过 parent.loadClass() 调用，等于主动切断双亲委派。这种操作在绝大多数场景下会导致严重问题：

重复加载核心类：比如你自己的类加载器去加载 java.lang.Object，JVM 会拒绝，抛出 LinkageError
破坏类唯一性：两个不同加载器加载的 ArrayList，哪怕字节码一模一样，也不能相互赋值，运行时报 ClassCastException
引发 NoClassDefFoundError：某个类由子加载器加载，但它依赖的 java.util.concurrent 类却被父加载器加载，而该类引用了子加载器未加载的辅助类，就会在初始化时失败

真正需要打破委派的场景极少，比如 JDBC 的 DriverManager 要主动用线程上下文类加载器（Thread.currentThread().getContextClassLoader()）去加载驱动，因为 DriverManager 是 Bootstrap 加载的，无法直接访问应用 classpath 下的驱动类。

调试时怎么确认委托是否发生

最直接的方式是加断点或日志：在自定义 ClassLoader 的 loadClass() 开头打印当前加载器身份和类名，在 findClass() 入口再打一次。你会看到类似这样的调用链：

AppClassLoader.loadClass("com.example.Service") →  
ExtClassLoader.loadClass("com.example.Service") →  
BootstrapClassLoader.loadClass("com.example.Service") →  
（返回 null）→  
ExtClassLoader.findClass("com.example.Service") →  
（找不到，返回 null）→  
AppClassLoader.findClass("com.example.Service")

注意两点：