【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 用表格狠狠区分这两个概念

比较维度	Java 继承关系（Inheritance）	双亲委派关系（Parent Delegation）
定义方式	由 class A extends B 在代码编译期确定	由 ClassLoader 构造方法传入的 parent 对象在运行时确定
表达意思	"A 是 B 的一种"（如 App 是一种 URLClassLoader）	"A 加载之前，先委托给 B 去加载"
ExtClassLoader	继承自 URLClassLoader	逻辑父是 Bootstrap（parent 字段为 null）
AppClassLoader	继承自 URLClassLoader	逻辑父是 ExtClassLoader
BootstrapClassLoader	无 Java 父类（C++ 编写）	无父加载器（至高级）

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

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

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

最终结论：

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

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

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

---

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

---