吃透JVM类加载：双亲委派、自定义加载、热加载实战，终于讲通透了！

恼书:-(空寄

532人浏览 · 2026-05-25 11:00:50

恼书:-(空寄 · 2026-05-25 11:00:50 发布

很多Java开发者写了五年代码，还停留在「会写CRUD、不懂底层加载逻辑」的阶段。平时new Object()、调用工具类、引入第三方依赖，看似平平无奇，背后全是JVM类加载机制在默默兜底。

双亲委派为什么存在？能不能打破？

今天这篇文章，抛开晦涩的官方文档，用通俗逻辑+实战代码，一次性讲透双亲委派、自定义类加载器、代码热加载三大核心知识点。

一、先搞懂：什么是类加载？

Java代码从编写到运行，核心经历三步：

源码.java → 编译.class字节码 → JVM加载Class对象 → 实例化运行

我们常说的类加载，就是JVM把磁盘上的\.class字节码文件，加载到内存、解析成可执行的Class对象的全过程。

很多人不知道：Java是动态加载语言，类并非启动时一次性全部加载，而是用到才加载、懒加载机制。而负责完成这一切的工具，就是——类加载器 ClassLoader。

JVM默认自带三层类加载器，各司其职、层级分明，这也是双亲委派模型的基础。

JVM三层原生类加载器（层级从高到低）

启动类加载器（Bootstrap ClassLoader）：最顶层，C++编写，加载JDK核心底层类，如java\.lang\.\*，开发者无法直接获取
扩展类加载器（Extension ClassLoader）：中层，加载JDK扩展包、系统拓展类
应用类加载器（App ClassLoader）：底层，我们日常开发的业务类、引入的第三方Jar包，全部由它加载，也是默认的系统类加载器

三层加载器并非继承关系，而是组合父级委派关系，这就引出了Java最经典的设计：双亲委派模型。

二、双亲委派：Java底层的安全基石

1. 通俗定义

很多人背了无数遍定义，却始终没理解核心。

双亲委派核心逻辑：子类加载器收到加载请求，绝不自己先加载，优先向上委托父加载器；父加载器无法加载时，子类才自行加载。

简单说就是：先上交、后自留，层层向上兜底。

2. 完整执行流程

当我们需要加载一个类时，流程严格固定：

App类加载器接收加载请求，向上委派给Extension加载器
Extension加载器继续向上委派给Bootstrap启动加载器
Bootstrap判断：是JDK核心类就直接加载，不是则返回无法加载
逐层向下退回，最终由App加载器加载普通业务类

3. 为什么必须设计双亲委派？两大核心价值

很多人疑惑：直接自己加载不就行了，多此一举分层委派干嘛？核心是安全+单一性。

① 核心类安全，防止恶意篡改

假设我们自己手写一个java\.lang\.String类，能不能覆盖JDK原生类？

答案：完全不能。

因为双亲委派机制会优先让顶层Bootstrap加载原生String类，自定义的同名类会被彻底屏蔽，杜绝了开发者篡改JDK核心类、植入恶意代码的风险，保障Java核心运行环境安全。

② 保证类全局唯一性

同一个类，被不同加载器加载会产生多个Class对象，引发类型转换异常、内存错乱。双亲委派确保一个类全局只被加载一次、唯一Class对象。

4. 双亲委派的底层源码核心

双亲委派的核心实现，就在ClassLoader的loadClass()方法中，核心逻辑极简：

// 双亲委派核心伪代码
protected Class<?> loadClass(String name, boolean resolve) {
    // 1. 先检查当前加载器是否已加载该类，避免重复加载
    Class<?> c = findLoadedClass(name);
    if (c == null) {
        try {
            // 2. 存在父加载器，优先委派父加载器加载
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                // 3. 顶层加载器，委派启动类加载器
                c = findBootstrapClassOrNull(name);
            }
        } catch (ClassNotFoundException e) {
            // 4. 父加载器全部无法加载，自己执行加载逻辑
            c = findClass(name);
        }
    }
    return c;
}

核心结论：想要打破双亲委派，本质就是重写loadClass()方法，改变默认委派逻辑。

三、为什么要打破双亲委派？自定义类加载器实战

双亲委派很好，但不是万能的。

在插件化开发、代码热更新、Jar包隔离、加密类加载、中间件框架开发场景，双亲委派的「向上委托、全局唯一」会变成枷锁。

这时候，就需要自定义类加载器，灵活打破原生规则。

1. 自定义类加载器核心原理

JDK规范：自定义类加载器只需继承ClassLoader，findClass()重写方法即可，禁止直接改写核心逻辑。

默认双亲委派逻辑在loadClass()中，我们只需在findClass()中实现自己的加载规则：从本地文件、网络、加密文件、数据库加载字节码，就能实现个性化加载。

2. 完整可运行自定义类加载器代码

import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;

/**
 * 自定义类加载器：实现本地class文件自定义加载
 * 可用于热加载、加密类加载、插件化场景
 */
public class CustomClassLoader extends ClassLoader {

    // 自定义class文件加载路径
    private final String classPath;

    public CustomClassLoader(String classPath) {
        this.classPath = classPath;
    }

    /**
     * 重写findClass：自定义字节码加载逻辑
     */
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        // 读取本地class字节码文件
        byte[] classData = getClassData(name);
        if (classData == null || classData.length == 0) {
            throw new ClassNotFoundException(name);
        }
        // 字节码转为Class对象
        return defineClass(name, classData, 0, classData.length);
    }

    /**
     * 读取本地class文件字节数组
     */
    private byte[] getClassData(String className) {
        String path = classPath + File.separator + className.replace(".", "/") + ".class";
        try (FileInputStream fis = new FileInputStream(path)) {
            byte[] buffer = new byte[fis.available()];
            fis.read(buffer);
            return buffer;
        } catch (IOException e) {
            return null;
        }
    }
}

3. 进阶：彻底打破双亲委派

上述代码只是扩展加载规则，并未打破双亲委派，依然会先走父加载器。

如果需要完全打破双亲委派、优先自己加载（热加载、插件隔离必备），直接重写loadClass()方法，倒置加载逻辑：

@Override
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 1. 优先检查自己是否已加载
    Class<?> clazz = findLoadedClass(name);
    if (clazz != null) {
        return clazz;
    }
    // 2. 核心：优先自己加载，不先委托父加载器（打破双亲委派核心）
    try {
        clazz = findClass(name);
    } catch (ClassNotFoundException e) {
        // 3. 自己加载失败，再委托父加载器兜底
        return super.loadClass(name, resolve);
    }
    return clazz;
}

4. 自定义类加载器核心应用场景

代码热加载/热部署：不停机更新业务代码
插件化架构：IDEA插件、SpringBoot插件、中间件插件，独立加载、隔离插件类
加密类加载：class文件加密，自定义加载器解密后加载，防止代码反编译泄露
Jar包版本隔离：不同模块依赖不同版本Jar，避免版本冲突（Tomcat、SpringCloud核心原理）

四、热加载：不停机更新代码的底层魔法

开发中最爽的功能莫过于热部署：修改代码无需重启服务，即时生效。

很多人只会用SpringBoot DevTools、JRebel，却不懂底层原理，其实热加载完全基于自定义类加载器+打破双亲委派实现。

1. 原生JVM为什么不支持热加载？

基于双亲委派机制，一个类加载器只能加载一个类一次，加载后会缓存Class对象，永久复用，不会重复加载。

哪怕你修改了class文件，JVM也不会重新加载，这就是原生不支持热更新的根源。

2. 热加载核心原理

想要实现热更新，核心就一句话：用全新的自定义类加载器，重新加载修改后的class文件。

核心逻辑：

监听class文件变动（修改、更新）
销毁旧的自定义类加载器
创建全新的自定义类加载器实例
新加载器重新加载最新class字节码，生成全新Class对象
替换旧类实例，实现代码不停机更新

3. 极简热加载落地Demo

public class HotLoadTest {
    public static void main(String[] args) throws Exception {
        while (true) {
            // 每次循环创建新的自定义加载器，实现热更新
            CustomClassLoader classLoader = new CustomClassLoader("target/classes");
            Class<?> clazz = classLoader.loadClass("com.example.DemoService");
            // 反射创建新实例，执行最新代码逻辑
            Object obj = clazz.getDeclaredConstructor().newInstance();
            clazz.getMethod("sayHello").invoke(obj);

            // 轮询监听，1秒刷新一次
            Thread.sleep(1000);
        }
    }
}