JVM 类加载机制实战：双亲委派、热重载与类隔离

JDK 9 之后还有一个容易踩的点：ClassLoader.getSystemClassLoader().getParent() 返回的是 Platform ClassLoader，不是 null。如果把自定义加载器的 parent 设成它，业务 JAR 反而加载不到——这是”自定义加载器写对了却报 ClassNotFoundException: com.fasterxml.jackson...“的常见原因。

三、什么时候必须打破双亲委派

三种真实场景几乎绕不开：SPI 扩展、容器隔离、插件热插拔。它们的共同诉求是”父加载器看不到的类，也得能被加载到”。

1. SPI / JDBC：java.sql.Driver 接口由 Bootstrap 加载，实现类（如 mysql-connector-j）在 classpath 里，Bootstrap 看不见。解法是线程上下文加载器 Thread.currentThread().getContextClassLoader()，由它去扫 META-INF/services。站内 Java SPI 实战：用 ServiceLoader 构建可插拔架构 已经把这一层拆开讲过，这里不重复。
2. Tomcat 等 Web 容器：每个 webapp 一个 WebappClassLoader，且顺序反过来——先自己找，再问父。目的是让应用自带的 Spring 版本优先于容器共享的版本，同时应用之间互不可见。
3. 热部署 / 插件框架：想替换一份类，唯一办法是新建一个 ClassLoader 去定义新版本，再把旧加载器和它的所有实例丢掉。JVM 不支持”就地修改已加载的类”。

顺带说明：像 ByteBuddy 实战：字节码增强与 Java Agent 这类运行时改字节码的工具，走的是 Instrumentation.redefineClasses 通道，属于 JVM 特批的”重定义”，和新建 ClassLoader 是两条完全不同的路——前者改方法体不改结构，后者能换整个类但对象身份会变。

四、写一个能热重载的 ClassLoader

第一步，实现一个从指定目录读取字节码的加载器。注意 parent 保留系统加载器，否则连 java.lang.Object 都要自己想办法。

public class DiskClassLoader extends ClassLoader {

    private final Path root;

    public DiskClassLoader(Path root) {
        super(ClassLoader.getSystemClassLoader()); // 父加载器：保证 JDK 与 classpath 可见
        this.root = root;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Path file = root.resolve(name.replace('.', '/') + ".class");
        try {
            byte[] bytes = Files.readAllBytes(file);
            return defineClass(name, bytes, 0, bytes.length); // name 必须与字节码内一致
        } catch (IOException e) {
            throw new ClassNotFoundException(name, e);
        }
    }
}

第二步做热重载。难点不在”加载新类”，而在”如何安全地调用它”。跨 ClassLoader 的对象不能强转成实现类，只能通过共享的接口或反射调用，否则必然 ClassCastException。下面用反射演示最小可用版本：

public class HotReloader {

    private record Snapshot(DiskClassLoader loader, Class<?> type, Object instance) { }

    private final Path pluginDir = Path.of("/opt/plugins");
    private volatile Snapshot current;

    public HotReloader() throws Exception {
        reload();
    }

    /** 每次调用都换一个新加载器，旧加载器失去引用后才能被回收 */
    public synchronized void reload() throws Exception {
        DiskClassLoader loader = new DiskClassLoader(pluginDir);
        Class<?> type = loader.loadClass("com.example.plugin.GreeterImpl");
        Object instance = type.getDeclaredConstructor().newInstance();
        Snapshot old = current;
        current = new Snapshot(loader, type, instance);
        System.out.printf("reload done, metaspace classes=%d%n",
                ManagementFactory.getClassLoadingMXBean().getLoadedClassCount());
        // old 在这里离开作用域，若无外部引用即可被 GC
    }

    public String greet(String who) throws Exception {
        Snapshot snap = current;                       // 先取快照，避免 reload 中途被换掉
        Method m = snap.type.getMethod("greet", String.class);
        return (String) m.invoke(snap.instance, who);
    }
}

这段代码真正要盯的是一个数字：getLoadedClassCount()。如果每次 reload 后它只增不减，说明旧 ClassLoader 没被回收，Metaspace 迟早 OOM。热重载的成败不取决于”新类加载成功”，而取决于”旧类能不能卸载”。

五、类隔离：同名冲突的根治方案

当一个 JVM 里要同时用 Jackson 2.13 和 2.17、或者两个插件都内置了 Netty，双亲委派下的”全局唯一”就成了枷锁。类隔离的本质是：让同一个全限定名在不同 ClassLoader 里各定义一次，两个 Class 对象不相等，自然互不干扰。

# 1) 看每个加载器加载了多少类、活了多久
jcmd <pid> VM.classloader_stats | sort -k6 -nr | head -20

# 2) 按类占用统计（需 -XX:+UnlockDiagnosticVMOptions 启动）
jcmd <pid> GC.class_stats | sort -k3 -nr | head -20

# 3) 打印类加载器摘要，观察同名加载器数量是否持续增长
jmap -clstats <pid>

# 4) 开启类卸载追踪，确认"该卸载的没卸载"
java -XX:+TraceClassUnloading -verbose:class -jar app.jar | grep -i unload

# ① 这个类到底是谁加载的
jcmd <pid> VM.class_hierarchy -i -s com.example.Foo

# ② 运行时打印真实加载器（临时排查代码，勿长期留在生产）
System.out.println(Foo.class.getClassLoader()
        + " -> " + Foo.class.getProtectionDomain().getCodeSource().getLocation());

# ③ 启动加 -verbose:class，grep 目标类，看加载来源 JAR
java -verbose:class -jar app.jar 2>&1 | grep "com.example.Foo"

# ④ 内部类 / 静态块的初始化异常会被包装成 NoClassDefFoundError
#    真实原因藏在 "Caused by: java.lang.ExceptionInInitializerError" 里