【Java 类加载器】Java 类加载器完整体系深度拆解（中）：URLClassLoader 能力剖析与继承委派辨析

作者介绍： 大家好，我是 CodeStats。一个在底层技术上“考古”了四年的硬核爱好者，也是 WWAIC（全周项目AI编程）范式的提出者和实践者。我曾手写过一个完整的 Java Web 框架（从 IoC 容器到嵌入式 Tomcat，代码全开源），也喜欢用通俗的语言拆解 CPU、JVM、操作系统的运行本质。我的技术信条：所有高深的技术，最后都能用大白话讲清楚。如果讲不清楚，说明还没真正理解。

本文能获得什么

• 厘清继承链： 彻底搞懂 URLClassLoader 在 Java 类加载器体系中的“工具人”定位

• 实战代码： 提供从本地文件、JAR 包、远程网络加载类的完整可运行示例

• 辨析核心概念（重点）： 把“Java 继承”和“双亲委派”这两个纠缠不清的概念彻底分开

• 击穿本质： 为什么 Bootstrap 不是 Java 类却能当最顶层的“爸爸”

目录

• 提问四：Java 的 URLClassLoader 和 Bootstrap、App、Ext 类加载器是什么关系

• 提问五：Java 的 URLClassLoader 应用场景及代码示例

• 提问六：Bootstrap、App、Ext 类加载器都继承自 URLClassLoader，为什么 Bootstrap 才是最顶层父类加载器，继承和实际父类加载器有何区别

四、Java 的 URLClassLoader 和 Bootstrap、App、Ext 类加载器是什么关系

4.1 先看 Java 继承体系下的“族谱”

从 Java 代码的 extends 继承关系来看：

text

java.lang.ClassLoader （抽象类，定义了类加载的核心骨架）
↑
java.security.SecureClassLoader （增加了对安全权限的支持）
↑
java.net.URLClassLoader （实现了从 URL 路径加载 .class 文件的核心能力）
↑ (extends) ↑ (extends)
sun.misc.Launcher$ExtClassLoader sun.misc.Launcher$AppClassLoader

结论： ExtClassLoader 和 AppClassLoader 都是 URLClassLoader 的子类，它们直接复用了 URLClassLoader 中通过 URL[] 路径查找类字节码的能力。

4.2 URLClassLoader 到底是个什么角色？

你可以把 URLClassLoader 理解为一个 “万能文件读取器”：
它知道怎么根据传入的 URL（可以是 file:/、jar:file:/、http://）去打开流、读取字节码、调用 defineClass() 变成 Class 对象。

而 Ext 和 App 类加载器，只不过是 提前配置好了特定 URL 路径 的两个 URLClassLoader 实例罢了：

• ExtClassLoader 构造时传入了 java.ext.dirs 对应的路径。

• AppClassLoader 构造时传入了 java.class.path（即 classpath）对应的路径。

BootstrapClassLoader 比较特殊，它完全绕过 Java 的继承体系，直接由 JVM C++ 代码操控内存去加载核心库。

4.3 一句话总结

URLClassLoader 是“干活的工具”，Ext 和 App 是“拿着工具干活的打工仔”，Bootstrap 是“站在 C++ 层的大老板”。

五、Java 的 URLClassLoader 应用场景及代码示例

5.1 核心应用场景

• 插件化架构： 主程序启动后动态扫描 /plugins 目录下的新 JAR 包并加载。

• 热部署： 通过新建新的 URLClassLoader 重新加载更新后的类文件，然后替换旧引用（老版本 Tomcat 的做法）。

• 从非 classpath 来源加载： 比如配置文件加密后放在特定目录，或者从远程 OSS 下载 class 字节码。

• 模块化隔离： 不同的业务模块使用不同的 URLClassLoader，防止类冲突（如 OSGi、Java 9 模块化前的常见做法）。

5.2 实战代码示例

示例一：从磁盘文件目录加载类（绕过 classpath）

java

import java.net.URL;
import java.net.URLClassLoader;
import java.io.File;

public class DiskPathLoaderDemo {
public static void main(String[] args) throws Exception {
// 假设 /opt/my_plugins/ 路径下有一个 com.example.PluginImpl.class
File pluginDir = new File("/opt/my_plugins/");
URL[] urls = { pluginDir.toURI().toURL() };

// 不指定 parent，默认父加载器是 AppClassLoader
try (URLClassLoader loader = new URLClassLoader(urls)) {
// 加载类（此处不会触发双亲委派向上查找，因为父加载器路径里没有）
Class<?> clazz = loader.loadClass("com.example.PluginImpl");
Object instance = clazz.getDeclaredConstructor().newInstance();
clazz.getMethod("run").invoke(instance);
}
}
}

示例二：动态加载外部 JAR 包中的类

java

import java.net.URLClassLoader;
import java.net.URL;
import java.io.File;

public class JarLoaderDemo {
public static void main(String[] args) throws Exception {
// 指向一个外部的第三方库 fastjson.jar
File jarFile = new File("/opt/libs/fastjson-2.0.0.jar");
URL[] urls = { jarFile.toURI().toURL() };

// 显式指定父加载器为系统类加载器
ClassLoader systemParent = ClassLoader.getSystemClassLoader();
try (URLClassLoader loader = new URLClassLoader(urls, systemParent)) {
// 加载 fastjson 中的 JSON 类
Class<?> jsonClazz = loader.loadClass("com.alibaba.fastjson.JSON");
// 甚至可以在这里用反射调用 JSON.toJSONString(obj)
System.out.println("Class loaded: " + jsonClazz.getName());
}
}
}

示例三：从网络 HTTP 服务器加载类文件

java

import java.net.URLClassLoader;
import java.net.URL;

public class NetworkLoaderDemo {
public static void main(String[] args) throws Exception {
// 假设你的 HTTP 服务器根目录下放着 com/example/NetworkClass.class
URL[] urls = { new URL("http://192.168.1.100:8080/classes/") };

try (URLClassLoader loader = new URLClassLoader(urls)) {
Class<?> clazz = loader.loadClass("com.example.NetworkClass");
System.out.println("Class from network: " + clazz);
}
}
}

六、Bootstrap、App、Ext 类加载器都继承自 URLClassLoader，为什么 Bootstrap 才是最顶层父类加载器，继承和实际父类加载器有何区别

这是整个类加载器体系中最绕、面试官最爱问、也最能区分“背答案”和“真理解”的问题。

6.1 先给出绝对正确的结论

• 前提修正： App 和 Ext 确实继承自 URLClassLoader，但 Bootstrap 不继承（因为它是 C++ 的）。

• 关键辨析： 继承关系（extends） 决定的是“我拥有什么能力”；双亲委派关系（parent 字段） 决定的是“我遇到加载请求先找谁帮忙”。

• 本质： Bootstrap 之所以是逻辑最顶层，是因为在 loadClass() 代码里，当 parent == null 时，默认调用的兜底方法就是指向 Bootstrap 的 findBootstrapClassOrNull()。

6.2 用表格狠狠区分这两个概念

6.3 为什么 Java 要搞得这么绕？

因为 Bootstrap 不住在 Java 对象体系里。Java 的 parent 字段要求类型必须是 ClassLoader 对象，而 Bootstrap 不是 Java 对象，没法赋值。

所以 Java 设计者只好约定：如果 parent == null，就自动视为父加载器是 Bootstrap。这是一种“隐式契约”。

最终结论：

• 从代码能力上看，App 和 Ext 都是 URLClassLoader 的儿子。

• 从加载顺序上看，App 听 Ext 的，Ext 听 Bootstrap 的。

• 继承是“基因”，双亲委派是“组织关系”。两者互不干扰，各自发挥作用。

（中篇完，请继续阅读下篇）