Java双亲委派模型能打破吗？ClassLoader实战教程

Java的双亲委派模型并非不可撼动的铁律，而是在实际工程中被高频、有目的地打破——从JDBC驱动加载、Tomcat应用隔离到Spring Boot可执行包和OSGi模块化，无不依赖对委派机制的主动绕过；但打破不等于随意重写，若忽略系统类委派、混淆线程上下文类加载器、误用Class.forName或跨加载器类型操作，轻则NoClassDefFoundError，重则运行时转型失败与反射异常；真正稳健的自定义ClassLoader，必须精准划分委派边界、严格隔离核心类、显式管控资源发现与类加载路径，并深刻理解“类加载器即类型宇宙”的本质——在这里，相同的类名、字节码，只要加载器不同，就是完全无法互通的两个世界。

双亲委派被打破是常态，不是例外

可以，而且在真实项目里几乎每天都在发生。双亲委派只是 ClassLoader.loadClass() 的默认实现逻辑，只要你重写这个方法、不调用 super.loadClass()，或者绕过它（比如直接调用 defineClass()），委派链就断了。JDBC 的 DriverManager、Tomcat 的 WebAppClassLoader、OSGi、Spring Boot 的 LaunchedURLClassLoader 全都主动打破了它——不是为了炫技，而是为了解决类隔离或热加载这类刚需。

重写 loadClass() 时最容易触发的 NoClassDefFoundError

很多人以为“重写 loadClass() 就是自己 new byte[] 然后 defineClass()”，结果一跑就崩。根本原因是：你没处理好系统类（如 java.lang.String）和接口类（如 java.util.List）的加载。这些类必须由启动类加载器或扩展类加载器提供，你自己定义出来的会因类加载器不同而无法赋值、强制转型失败。

正确做法是：先判断是否为系统类/核心类，优先委派给父加载器；再处理自定义路径的类；最后才 fallback 到自己的 findClass()。示例关键片段：

protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
    if (name.startsWith("java.") || name.startsWith("javax.")) {
        return super.loadClass(name, resolve); // 必须走默认委派
    }
    Class c = findLoadedClass(name);
    if (c == null) {
        c = findClass(name); // 自己加载
    }
    if (resolve) resolveClass(c);
    return c;
}

Tomcat 和 Spring Boot 的自定义 ClassLoader 差在哪

两者都打破双亲委派，但动机和边界完全不同：

• Tomcat 的 WebAppClassLoader：优先从 WEB-INF/classes 和 WEB-INF/lib 加载，仅当找不到时才委派给父类加载器。这是典型的“逆向委派”，目的是让应用类覆盖容器提供的同名类（比如不同版本的 commons-collections）。
• Spring Boot 的 LaunchedURLClassLoader：把 BOOT-INF/classes 和 BOOT-INF/lib 放在委派链最前面，但对 org.springframework.* 这类核心包仍会委派给父加载器（即 AppClassLoader），避免启动类被重复加载或冲突。

关键差异在 getResource() 和 getResources() 的实现：Tomcat 会屏蔽父加载器的同名资源，Spring Boot 则保留父加载器结果并合并——这直接影响 ServiceLoader 是否能发现 META-INF/services 下的实现类。

自定义 ClassLoader 后，Class.forName() 和 ClassLoader.getSystemClassLoader() 会出什么问题

这两个是隐形陷阱高发区：

• Class.forName("com.example.Foo") 默认使用当前线程上下文类加载器（Thread.currentThread().getContextClassLoader()），不是当前类所在加载器。如果你没显式设置上下文类加载器，它很可能还是 AppClassLoader，导致你的自定义类根本加载不到。
• ClassLoader.getSystemClassLoader() 永远返回 JVM 启动时的系统类加载器（通常是 AppClassLoader），它跟你的自定义实例完全无关。别指望用它来加载你自己的 jar 包。
• 反射调用 newInstance() 或 getMethod() 时，如果参数类型来自不同类加载器，哪怕类名、字节码一模一样，也会报 IllegalArgumentException 或 NoSuchMethodException——因为 JVM 认为它们是“不同的类”。

真正可控的方式只有两个：显式传入你的 ClassLoader 实例调用 loadClass()，或者提前设置线程上下文类加载器：Thread.currentThread().setContextClassLoader(myCl)。

类加载器边界比 package 名称更硬，跨加载器的 instanceof、强制转型、异常捕获全都会失效。这点一旦忽略，调试成本远高于写加载逻辑本身。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Java双亲委派模型能打破吗？ClassLoader实战教程》文章吧，也可关注golang学习网公众号了解相关技术文章。