目录

Java 插件化架构体系演进：从 JPF、OSGi、PF4J 到 Java 9 JPMS

插件化架构（Plugin Architecture / Microkernel Architecture）是一种将系统核心功能与业务扩展能力解耦的经典架构模式。在 Java 生态中，插件化机制经历了从早期的 JPF (Java Plugin Framework)、企业级动态模块化巨擘 OSGi，到现代轻量级标杆 PF4J (Plugin Framework for Java)，再到官方标准 Java 9 JPMS (Jigsaw) 的长期演进。

本文将深入剖析 Java 插件体系的核心底层原理、JPMS 与插件系统的差异，并详细解答插件热部署的技术落地机制以及JVM 如何防止 JDK 核心类被恶意替换。

Java 插件体系的核心底层基石

无论是哪种插件框架，在 JVM 层面都需要解决三个核心技术挑战：

D2 Diagram
qtopie.github.io

类加载器隔离 (ClassLoader Isolation)

Java 默认的双亲委派模型（Parent-First Delegation）无法直接满足插件化系统对“依赖隔离”和“版本冲突解决”的要求。

扩展点与契约机制 (Extension Point & Extension)

动态生命周期管理 (Lifecycle Management)

插件的状态通常包括：INSTALLED（已安装） $\rightarrow$ RESOLVED（已解析） $\rightarrow$ ACTIVE（已启动） $\rightarrow$ STOPPED（已停止） $\rightarrow$ UNINSTALLED（已卸载）。

深入双亲委派模型（基于 JDK 17 / Java 9+ 现代架构）

要真正理解插件框架的隔离机制，必须深刻掌握 JVM 的**双亲委派模型（Parent Delegation Model）**及其在现代 JDK 17 中的架构演进。

D2 Diagram
qtopie.github.io

什么是双亲委派模型？

当一个类加载器收到类加载请求时：

  1. 它不会自己先去尝试加载这个类，而是把这个请求委派给父类加载器去完成。
  2. 每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器（Bootstrap ClassLoader）中。
  3. 只有当父类加载器反馈自己无法完成这个加载请求（在其搜索范围内没有找到所需的类）时，子加载器才会尝试自己去加载。

核心作用

JDK 17 相比 JDK 8 的重大类加载体系演进

在 JDK 9 引入模块化系统（JPMS）并在 JDK 17 LTS 中成熟后，类加载器体系发生了根本性重构：

对比维度经典 JDK 8 体系现代 JDK 17 / 21 体系
基础类存放载体jre/lib/rt.jar 与 tools.jar彻底废除 rt.jar，改为 JImage 模块包 lib/modules
扩展类加载器Extension ClassLoader（加载 jre/lib/ext/*.jar）彻底废除 ExtClassLoader，由 Platform ClassLoader 替代
启动类加载器纯 C++ 实现，Java 中表示为 nullC++ 与 Java 协同，提供 jdk.internal.loader.ClassLoaders$BootClassLoader
基础实现基类java.net.URLClassLoader统一继承自 jdk.internal.loader.BuiltinClassLoader
委派与查找策略纯线性自底向上委派增加模块归属映射（Module Mapping）：若类属于指定具名模块，直接路由至对应 Loader

JDK 17 核心类加载器分工

  1. Bootstrap ClassLoader（启动类加载器）：
    • 负责加载核心基础模块（如 java.base、java.logging、java.prefs 等）。
  2. Platform ClassLoader（平台类加载器）：
    • 替代了原有的 ExtClassLoader。负责加载 Java SE 平台中其余的标准模块（如 java.sql、java.xml、java.desktop、java.net.http 及部分 jdk.* 模块）。
  3. AppClassLoader（应用程序类加载器）：
    • 负责加载传统的 -classpath / -cp 路径下的 JAR 包，以及 --module-path 中的应用程序自定义模块。

Platform ClassLoader 与 ExtClassLoader 的深度差异

很多开发者容易把 Platform ClassLoader 简单理解为“改了个名字的 ExtClassLoader”，但实际上二者的设计定位、加载逻辑与安全模型有着根本性不同：

对比维度传统 ExtClassLoader (JDK 8 及以前)现代 Platform ClassLoader (JDK 9 ~ JDK 17+)
设计背景传统的 Java 扩展目录机制（Extension Mechanism）模块化系统（JPMS）中的平台模块解耦
实现类sun.misc.Launcher$ExtClassLoaderjdk.internal.loader.ClassLoaders$PlatformClassLoader
继承基类java.net.URLClassLoader内部定制的 jdk.internal.loader.BuiltinClassLoader
类加载来源扫描本地物理目录：jre/lib/ext/*.jar 或 -Djava.ext.dirs直接读取 JImage 镜像文件（lib/modules）中的指定平台模块
加载的内容扔在 ext 目录下的任意第三方/扩展 JAR 包只加载非核心的 Java SE / JDK 标准平台模块（如 java.sql、java.xml、java.net.http 等）
用户能否塞包可以（将 jar 扔进 jre/lib/ext 即可被加载）不行（ext 机制被彻底废除，用户 jar 只能通过 classpath 或 module-path 加载）
类查找机制纯线性自底向上扫描磁盘物理 Jar具备模块映射能力（Module Mapping），直接根据类索引精准路由
安全权限默认赋予 AllPermission 极高权限遵循标准模块安全策略，不再赋予无节制的特权

为什么 JDK 9+ 必须废除 ExtClassLoader？

  1. 隐式类污染与依赖地狱：只要有人在运行环境的 jre/lib/ext 目录下放了一个旧版第三方 jar 包，该机器上运行的所有 Java 进程都会无条件优先加载它（优先级高于 AppClassLoader），导致本地开发正常、生产环境却频发隐蔽的 NoSuchMethodError。
  2. 安全提权漏洞：ExtClassLoader 默认给扩展目录下的所有类授予极高的全量安全权限，恶意代码若潜入 ext 目录极易造成提权攻击。

历史兼容提示：java.ext.dirs 在 JDK 17 中的表现

JDK 17 源码机制：双亲委派如何执行？

在 JDK 17 的 java.lang.ClassLoader.loadClass(String name, boolean resolve) 中：

protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 1. 首先检查该类是否已经被当前加载器加载过（查询本地方法区/元空间缓存）
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // 2. 如果父加载器不为空，先委派给父加载器
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    // 父加载器为 null，说明父级是 Bootstrap ClassLoader
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父类加载器找不到，抛出异常并捕获，不中断流程
            }

            if (c == null) {
                // 3. 父加载器均无法加载时，调用自身的 findClass 进行读取和解析
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

JDK 17 的优化：在 BuiltinClassLoader 中，如果请求加载的类属于一个已加载的 Named Module（具名模块），JVM 会直接根据模块定义快速定位并委派给加载该模块的专属 ClassLoader，大幅提升了查找效率。

插件框架为什么要“破坏”双亲委派？如何破坏？

为什么要打破？

在标准双亲委派机制下，父加载器（宿主 AppClassLoader）具有绝对优先权：

插件框架的解法：Child-First（先子后父 / 破坏双亲委派）

插件框架（如 PF4J、OSGi、Tomcat WebAppClassLoader）自定义重写了 loadClass 逻辑：

public class PluginClassLoader extends URLClassLoader {
    private final ClassLoader hostClassLoader;

    @Override
    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (getClassLoadingLock(name)) {
            // 1. 检查是否已经加载过
            Class<?> loadedClass = findLoadedClass(name);
            if (loadedClass != null) {
                return loadedClass;
            }

            // 2. 关键安全红线：JDK 核心类 (java.*) 必须强制走原生双亲委派！
            if (name.startsWith("java.")) {
                return super.loadClass(name, resolve);
            }

            // 3. Child-First：优先在插件自身的 jar / classes 中查找 (findClass)
            try {
                Class<?> pluginClass = findClass(name);
                if (resolve) {
                    resolveClass(pluginClass);
                }
                return pluginClass; // 自身找到，直接返回！成功实现多版本隔离
            } catch (ClassNotFoundException e) {
                // 插件自身没有该类，降级回退到宿主加载器
            }

            // 4. 插件自身没有（如公共 API 接口、宿主导出的类），委派给宿主加载器
            return hostClassLoader.loadClass(name);
        }
    }
}

通过这种 Child-First（自身优先 $\rightarrow$ 宿主兜底） 模式，插件可以拥有独立的私有依赖空间，彻底终结了“JAR 地狱”依赖冲突。

线程上下文类加载器 (TCCL)：SPI 逆向加载的破局利器

除了插件框架主动破坏双亲委派外，JDK 自身还提供了一个历史悠久且极为关键的“开后门”机制——线程上下文类加载器（Thread Context ClassLoader, TCCL），它是解决 SPI（Service Provider Interface）逆向加载困境 的核心支柱。

D2 Diagram
qtopie.github.io

1. 线程的 ContextClassLoader 到底从哪里来？

很多开发者好奇：Thread.currentThread().getContextClassLoader() 返回的对象究竟是谁在什么时候设置进去的？

第一阶段：JVM 启动与主线程赋初值

在 JVM 启动引导阶段（System.initPhase3 / Launcher 初始化）：

  1. JVM 依次构建出 Bootstrap ClassLoader、Platform ClassLoader 和 AppClassLoader。
  2. 在构建主线程（main 线程）时，JVM 会显式调用：
    // JVM 引导期源码逻辑
Thread.currentThread().setContextClassLoader(appClassLoader);
    至此，主线程的 TCCL 被正式锚定为 AppClassLoader。

第二阶段：线程树的上下文继承机制

当在业务代码中调用 new Thread(...)、CompletableFuture.runAsync(...) 或通过线程池创建新线程时，查看 JDK java.lang.Thread 的初始化源码：

// java.lang.Thread 内部构造核心逻辑
private void init(ThreadGroup g, Runnable target, String name, long stackSize, AccessControlContext acc) {
    Thread parent = currentThread(); // 获取当前创建子线程的父线程
    // ...
    // 关键：子线程无条件默认继承父线程的 ContextClassLoader！
    this.contextClassLoader = parent.getContextClassLoader();
    // ...
}

结论：只要没有人工调用 setContextClassLoader(...) 强行修改，全系统所有由主线程衍生出来的业务线程、连接池线程和工作线程，其 TCCL 默认全部指向 AppClassLoader。

2. 端到端实战：当我们用 MySQL Driver 查询数据库时，类是如何被拿到的？

以最经典的数据库查询语句为例：

// 业务代码发起调用
Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/db", "root", "123");

整个驱动类从被发现、加载到实例化的全过程如下：

步骤一：触发 DriverManager 类初始化与静态代码块

DriverManager 位于 java.sql 模块（由 Platform ClassLoader 加载）。当它第一次被业务调用时，触发执行静态初始化块：

public class DriverManager {
    static {
        loadInitialDrivers(); // 关键入口！
        println("JDBC DriverManager initialized");
    }
    // ...
}

步骤二：loadInitialDrivers() 通过 TCCL 发起 SPI 服务发现

查看 DriverManager.loadInitialDrivers() 底层源码：

private static void loadInitialDrivers() {
    // 1. ServiceLoader.load(Driver.class) 底层默认获取当前线程的 TCCL
    // 等价于：ServiceLoader.load(Driver.class, Thread.currentThread().getContextClassLoader());
    ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);

    // 2. 拿到迭代器（此时尚未触发真正的类加载）
    Iterator<Driver> driversIterator = loadedDrivers.iterator();
    try {
        while (driversIterator.hasNext()) {
            driversIterator.next(); // 关键动作：推进迭代器，触发具体类的加载与实例化！
        }
    } catch (Throwable t) {
        // ...
    }
}

步骤三：ServiceLoader 使用 TCCL 加载第三方 Driver 实现

ServiceLoader 拿到了当前线程绑定的 AppClassLoader：

  1. 它在应用程序的 Classpath 下所有 Jar 包中查找 META-INF/services/java.sql.Driver 清单文件。
  2. 在导入的 mysql-connector-j-8.x.jar 中找到了该文件，内容为字符串：com.mysql.cj.jdbc.Driver。
  3. ServiceLoader 执行类加载动作：
    Class<?> c = Class.forName("com.mysql.cj.jdbc.Driver", true, tccl);
Driver driver = (Driver) c.getConstructor().newInstance();
    因为传入的 tccl 是 AppClassLoader，它能够直接访问和加载应用依赖路径下的 MySQL Jar 包，成功打破了 Platform/Bootstrap 无法向下找类的死结！

步骤四：MySQL 驱动在静态块中完成自我注册

当 com.mysql.cj.jdbc.Driver 类被加载时，它的静态代码块被自动触发：

package com.mysql.cj.jdbc;

public class Driver extends NonRegisteringDriver implements java.sql.Driver {
    static {
        try {
            // 向高层的 DriverManager 注册自身单例
            java.sql.DriverManager.registerDriver(new Driver());
        } catch (SQLException E) {
            throw new RuntimeException("Can't register driver!");
        }
    }
}

此时，DriverManager 内部维护的静态列表 registeredDrivers 成功持有了 MySQL Driver 的实例引用。

步骤五：getConnection 匹配并返回可用物理连接

最后，DriverManager.getConnection() 遍历已注册的驱动列表，调用 driver.acceptsURL("jdbc:mysql://...")。MySQL Driver 识别出这是自己的协议头并返回 true，随后调用 driver.connect(...) 建立 TCP Socket 连接并返回数据库 Connection 对象。

3. TCCL 在插件化架构（PF4J / OSGi / Spring）中的标准调度范式

在插件化和微内核系统中，宿主线程调用插件代码时，插件内部可能使用了 Jackson、Spring、Hibernate 或 SPI 等依赖 TCCL 的第三方库。

为了防止这些库用宿主的 AppClassLoader 去找类而报错，宿主在调度插件时必须执行标准的“类加载器上下文切换”三部曲：

public <T> T executeInPluginContext(PluginWrapper plugin, Callable<T> task) throws Exception {
    // 1. 暂存当前宿主线程的类加载器
    ClassLoader originalCl = Thread.currentThread().getContextClassLoader();
    try {
        // 2. 将当前线程上下文临时切换为该插件专属的 PluginClassLoader
        Thread.currentThread().setContextClassLoader(plugin.getPluginClassLoader());
        
        // 3. 执行插件核心逻辑（此时插件内部所有的 SPI、反射、反序列化均使用插件自身的依赖版本）
        return task.call();
    } finally {
        // 4. 必须在 finally 块中将 TCCL 还原，防止线程池复用引发上下文污染与内存泄漏！
        Thread.currentThread().setContextClassLoader(originalCl);
    }
}

深入剖析：为什么 plugin.getExtension().execute() 内部会用到 TCCL？

很多开发者会问：“plugin.getExtension() 返回的对象本身不就是由 PluginClassLoader 加载的吗？它执行方法时难道不能直接找到插件的类吗？为什么还需要显式切换 TCCL？”

答案是：对于代码中直接 new 的类不需要 TCCL；但对于插件内部调用的通用开源框架，必须依赖 TCCL！

D2 Diagram
qtopie.github.io
场景 A：静态直接引用（纯 new 关键字，不依赖 TCCL）

如果在插件方法内部写：MyHelper helper = new MyHelper();

场景 B：通用框架的动态反射与服务发现（必须依赖 TCCL）

当插件内部引入并调用了 Spring、Jackson、JDBC、ServiceLoader、Log4j、XML 解析器 等通用框架时，这些框架的代码通常是由**宿主类加载器（AppClassLoader）加载的。 当框架在运行期需要根据“字符串类名”、“注解”或“SPI 配置文件”**去动态查找插件内的类时，框架内部不知道插件的类加载器变量叫什么，唯一行业通用的标准做法就是调用 Thread.currentThread().getContextClassLoader()！

三大经典框架的底层源码佐证：

  1. Spring 容器扫描 Bean： org.springframework.util.ClassUtils.getDefaultClassLoader() 源码中写死：优先返回 Thread.currentThread().getContextClassLoader()。如果宿主没切换 TCCL，Spring 拿到的就是宿主加载器，直接导致插件内的 @Component 和配置类报 ClassNotFoundException。
  2. ServiceLoader 服务发现： ServiceLoader.load(Type.class) 底层无参重载方法直接等价于 ServiceLoader.load(Type.class, Thread.currentThread().getContextClassLoader())。
  3. Jackson / Fastjson 反序列化多态对象： 在根据 JSON 中的 @type 或类名字符串动态反射创建对象时，底层通过 Class.forName(className, true, Thread.currentThread().getContextClassLoader()) 来查找类。

核心结论：宿主在调度插件执行前切换 TCCL，本质上是为插件内部调用的所有第三方基础设施框架“铺平道路”，使这些框架能够透明、无缝地检索到插件自身的私有类与资源文件。

显式 ClassLoader 传参 vs 隐式 TCCL：它的底层本质是什么？

很多开发者会产生一个极具洞察力的疑问：“技术上我们完全可以直接用 myClassLoader.loadClass(...) 显式创建对象，那 TCCL 到底算什么？”

4. 插件内创建子线程：ClassLoader 会自动继承吗？（三种场景与避坑指南）

在编写插件业务逻辑时，多线程异步处理是常见需求。很多开发者困惑：在插件中创建的子线程，其 ClassLoader 会自动继承当前插件的 PluginClassLoader 吗？

这取决于具体的线程创建与调度方式：

场景一：使用 new Thread(...) 直接创建 $\rightarrow$ 会自动继承

如果在插件内部直接 new Thread(...)：

场景二：异步提交给宿主公共线程池 $\rightarrow$ 不会继承（极易踩坑）

如果插件把任务提交给了宿主传入的公共线程池（如 hostExecutor.submit(task)）：

public class PluginTaskWrapper {
    public static Runnable wrap(Runnable task) {
        // 1. 在提交任务的主调线程抓取插件 ClassLoader
        ClassLoader pluginCl = Thread.currentThread().getContextClassLoader();

        return () -> {
            // 2. 在执行任务的 Worker 线程中暂存其原本的 ClassLoader
            ClassLoader originalCl = Thread.currentThread().getContextClassLoader();
            try {
                // 3. 临时切换 Worker 线程的 TCCL 为插件加载器
                Thread.currentThread().setContextClassLoader(pluginCl);
                task.run();
            } finally {
                // 4. 必须还原 Worker 线程的 ClassLoader，防止线程池被长期污染
                Thread.currentThread().setContextClassLoader(originalCl);
            }
        };
    }
}

// 插件调用方式：
hostExecutor.execute(PluginTaskWrapper.wrap(() -> {
    // 安全执行插件内部逻辑，依赖和类加载均正常！
    doAsyncPluginWork();
}));

场景三：在插件内部维护私有线程池 $\rightarrow$ 会继承，但卸载时必须显式 Shutdown

如果插件在 start() 方法中自己创建了专属的 new ThreadPoolExecutor(...)：

JPF (Java Plugin Framework)

JPF 是早期受 Eclipse 3.0 插件机制 启发而诞生的开源 Java 插件框架，流行于 2004–2010 年代。

架构设计与核心概念

JPF 深度借鉴了 Eclipse Equinox 之前的早期插件设计思想：

JPF 的局限性与历史地位

OSGi (Open Services Gateway initiative)

OSGi 是 Java 领域功能最强大、标准最完备，但同时也是复杂度最高、学习曲线最陡峭的动态模块化规范与运行时容器（典型实现包括 Eclipse Equinox、Apache Felix、Knopflerfish）。

D2 Diagram
qtopie.github.io

OSGi 三层架构模型

OSGi 规范将系统划分为三层清晰的抽象：

模块层 (Module Layer)

生命周期层 (Lifecycle Layer)

服务层 (Service Layer)

OSGi 的优势与落地痛点

PF4J (Plugin Framework for Java)

PF4J 是目前 Java 生态中最流行、最轻量、上手成本最低的现代插件化框架。它摒弃了 OSGi 繁重的规范包袱，专注于提供极简实用的插件机制。

D2 Diagram
qtopie.github.io

PF4J 核心设计与使用范式

1. 定义扩展点

public interface GreetingExtension extends ExtensionPoint {
    String getGreeting(String name);
}

2. 插件实现扩展点

通过 @Extension 注解标记实现类（PF4J 在编译期通过 APT 自动生成 extensions.idx 索引，零运行时反射扫描）：

public class WelcomePlugin extends Plugin {
    public WelcomePlugin(PluginWrapper wrapper) {
        super(wrapper);
    }

    @Extension
    public static class ChineseGreeting implements GreetingExtension {
        @Override
        public String getGreeting(String name) {
            return "你好，" + name;
        }
    }
}

3. 宿主加载与调用

PluginManager pluginManager = new DefaultPluginManager();
pluginManager.loadPlugins();
pluginManager.startPlugins();

List<GreetingExtension> greetings = pluginManager.getExtensions(GreetingExtension.class);
for (GreetingExtension greeting : greetings) {
    System.out.println(greeting.getGreeting("World"));
}

Java 9 模块化系统 (JPMS / Jigsaw) 与插件化的关系

在 Java 9 中，官方引入了标准的 JPMS (Java Platform Module System)，通过 module-info.java 定义模块：

module com.example.plugin {
    requires com.example.host.api;
    provides com.example.host.api.GreetingService with com.example.plugin.DefaultGreeting;
    exports com.example.plugin.api;
}

JPMS 解决的核心问题

  1. 强封装性 (Strong Encapsulation)：即使是 public 类，如果所在包未在 module-info.java 中 exports 或 opens，外部即使使用反射也无法访问（彻底消灭非法内部 API 访问）。
  2. 可靠的配置 (Reliable Configuration)：在 JVM 启动期静态解析依赖图，缺包或循环依赖立即报错，消灭运行期的 NoClassDefFoundError。
  3. JDK 自身瘦身与定制：通过 jlink 工具根据依赖的模块裁剪出几十 MB 的专属最小 JRE。

为什么 JPMS 不能直接替代 OSGi / PF4J 插件系统？

对比维度Java 9 JPMS (模块化系统)OSGi / PF4J (插件化系统)
设计核心目标静态构建、启动期依赖校验与强封装运行期动态扩展、生命周期管理与热插拔
生效时机编译期与启动期（静态）运行期（动态）
动态加载/卸载原生不支持动态卸载（Layer 动态创建极其复杂）原生支持插件动态安装、启动、停止、卸载
类加载器模型默认采用同一 Application ClassLoader 分区为每个插件分配独立的 PluginClassLoader 解决依赖冲突
多版本共存原生不支持（同一 Layer 下同一模块只能有一个版本）天然支持（不同插件 ClassLoader 可各自加载不同版本）

结论：JPMS 是“静态模块系统”，而 OSGi/PF4J 是“动态插件容器”。在现代架构中，两者可以结合：JPMS 负责宿主内部包的强封装，PF4J / OSGi 负责运行期的业务插件动态加载与依赖隔离。

核心专题一：Java 插件热部署与类卸载落地机制

热部署（Hot-Reloading）的核心本质是：利用新的 ClassLoader 加载新代码，并将旧 ClassLoader 及其加载的所有 Class 和实例彻底送入垃圾回收。

D2 Diagram
qtopie.github.io

完整执行步骤

  1. 创建全新加载器：为新版本插件创建全新的 PluginClassLoader 实例。
  2. 加载并实例化：新 ClassLoader 读取新 JAR 包中的 .class，通过反射或 IoC 容器创建新的插件实例。
  3. 原子替换引用：宿主使用 AtomicReference 或读写锁，将扩展点实例指针原子切换到新实例上，使后续请求路由至新代码。
  4. 触发旧插件销毁钩子：调用旧插件的 stop() 或 destroy() 方法，关闭数据库连接、线程池、文件句柄等资源。
  5. 彻底切断所有强引用：将旧插件实例、旧 ClassLoader 引用全部置为 null（从宿主的缓存 Map、监听器列表、Spring 容器中移除）。
  6. JVM GC 回收与类卸载：当旧 ClassLoader 不存在任何 GC Roots 强引用时，Full GC 将回收 ClassLoader、其加载的所有 Class<?> 对象，并释放 Metaspace 元空间内存。

为什么插件热部署极易发生 Metaspace 内存泄漏？

JVM 规定：只要一个 ClassLoader 加载的任何一个 Class 还有一个活着的实例对象或静态引用，该 ClassLoader 就永远无法被卸载！

常见泄漏源及防范：

核心专题二：JVM 如何防止 JDK 核心类被自定义类加载器替换？

黑客或第三方插件是否可以通过编写一个 java.lang.String 并用自定义 ClassLoader 加载，从而篡改系统的字符串核心逻辑？

JVM 通过 “三大防线” 严格阻止了这种篡改行为：

D2 Diagram
qtopie.github.io

第一道防线：双亲委派机制的自然拦截

默认情况下，自定义类加载器调用 loadClass("java.lang.String") 时，会逐层向上委派至最高级别的 启动类加载器（Bootstrap ClassLoader）。 Bootstrap ClassLoader 会直接在 rt.jar（或 Java 9+ 的 java.base 模块）中找到官方正版的 java.lang.String 并返回。自定义的 .class 字节码根本没有机会被加载。

第二道防线：ClassLoader.defineClass 的底层强制安全校验

如果开发者故意重写 loadClass() 破坏双亲委派机制，直接读取恶意字节码并强行调用 defineClass("java.lang.String", bytes, ...)，会怎样？

查看 JDK java.lang.ClassLoader 的底层源码：

protected final Class<?> defineClass(String name, byte[] b, int off, int len,
                                     ProtectionDomain protectionDomain)
    throws ClassFormatError {
    
    // 核心安全红线检测！
    if ((name != null) && name.startsWith("java.")) {
        throw new SecurityException
            ("Prohibited package name: " + name.substring(0, name.lastIndexOf('.')));
    }
    // ...
}

第三道防线：Java 9+ 模块化系统的密封性与完整性保障

在 Java 9+ 体系中，核心 JDK 类全部封装在核心模块 java.base 中：

JPF vs OSGi vs PF4J vs JPMS 全方位对比

评估维度JPFOSGi (Equinox/Felix)PF4JJava 9 JPMS
定位范畴早期 XML 插件框架企业级动态模块系统现代轻量级插件框架官方静态模块化规范
主要生效阶段运行期运行期运行期编译期与启动期
类依赖隔离树状 ClassLoader复杂网状 ClassLoader扁平 Child-First ClassLoader单一 ClassLoader 模块分区
动态热插拔弱极强（完整状态机）中等（易于控制）无（需极其复杂的动态 Layer）
多版本共存支持原生强支持支持不支持（同名模块唯一）
Spring 生态融合困难复杂极简（pf4j-spring）良好（Spring 6+ 原生支持）
开发与维护成本中等极高（学习曲线陡峭）极低（半天快速上手）低（声明式 module-info）