Java面试之双亲委派模型及其破坏方式_技术教程

双亲委派模型是类加载的强制约定：类加载器收到请求后先委派父加载器，直至BootstrapClassLoader；父无法加载时子才自行加载，核心目的是保障核心类隔离与一致性。

双亲委派模型到底是什么，不是“先让父类加载器试一遍”那么简单

双亲委派不是一句口号，而是一套强制约定：当一个 ClassLoader 收到类加载请求时，它不会自己先去加载，而是把请求委派给 parent（父加载器），层层向上，直到到达 BootstrapClassLoader；只有父加载器无法完成加载（比如在它的路径下找不到该类），子加载器才尝试自己加载。

这个机制的核心目的不是“复用”，而是**隔离与一致性**：确保 java.lang.String 这种核心类永远由启动类加载器加载，避免被用户自定义的同名类替换，防止运行时冲突和安全漏洞。

注意：BootstrapClassLoader 是 C++ 实现、没有 Java 对象引用，所以它的 parent 是 null；ExtClassLoader 的 parent 是 null（不是 Bootstrap），AppClassLoader 的 parent 才是 ExtClassLoader。别记反了。

为什么 `Thread.getContextClassLoader()` 会破坏双亲委派

这是最常见也最容易被忽略的破坏方式。JDBC 就是典型：DriverManager 是由启动类加载器加载的（在 rt.jar 中），但它需要加载用户提供的 com.mysql.cj.jdbc.Driver —— 这个类显然不在 BootstrapClassLoader 的路径里。

解决办法是：DriverManager 内部不直接用 Class.forName()，而是调用 Thread.currentThread().getContextClassLoader().loadClass()。这个上下文类加载器默认是 AppClassLoader，于是绕过了双亲委派链，实现了“父加载器请求子加载器干活”的逆向委托。

这种破坏是**有意为之且必要**的，属于“服务提供者接口（SPI）场景”
但风险在于：如果线程上下文类加载器被错误设置（比如设成了自定义的、范围过窄的加载器），就会抛 ClassNotFoundException
Web 容器（如 Tomcat）也大量依赖此机制实现应用间类隔离

自定义 `ClassLoader` 重写 `loadClass()` 就算破坏双亲委派吗

不一定。关键看你怎么重写。

标准写法是这样的：

protected Class loadClass(String name, boolean resolve) throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) c = parent.loadClass(name, resolve); // ✅ 委派给父
                else c = findBootstrapClassOrNull(name);                 // ✅ 委派给 Bootstrap
            } catch (ClassNotFoundException e) {
                c = findClass(name); // ❌ 父失败后才自己找
            }
        }
        if (resolve) resolveClass(c);
        return c;
    }
}

如果你删掉委派逻辑，直接在 loadClass() 里调用 findClass()，那就彻底破坏了；但更常见的“破坏”其实是**重写 findClass() + 指定不同资源路径**，这不算违规——双亲委派只管“谁来触发加载”，不管“从哪读字节码”。

真正危险的是：在 findClass() 里又 new 了一个别的 ClassLoader 去加载，造成加载器树混乱
热部署、OSGi、模块化（JPMS）都依赖对委派逻辑的精细控制，不是简单“绕过”就行
JDK 9+ 的模块系统引入了 ModuleLayer 和 Configuration，双亲委派在模块边界上已不完全适用

`tomcat/webapps/xxx/WEB-INF/lib` 下的类为什么不会被 AppClassLoader 加载

因为 Tomcat **没用默认的双亲委派顺序**。它为每个 Web 应用创建独立的 WebAppClassLoader，其委派策略是：先尝试自己加载（即查 WEB-INF/classes 和 WEB-INF/lib），失败后再委派给父加载器（SharedClassLoader → CommonClassLoader → AppClassLoader）。

这就是“反双亲委派”（或称“本地优先”）：确保应用自己的 spring-core-5.3.30.jar 不会被容器共享的 spring-core-4.2.9.jar 覆盖。

这种破坏必须配合严格的类加载器隔离（比如不同应用的 WebAppClassLoader 互不可见）
若应用用了 Thread.currentThread().setContextClassLoader() 却没恢复，可能引发 ClassCastException（同一类被两个不同加载器加载，类型不兼容）
排查类加载问题时，别只看 ClassLoader.getSystemClassLoader()，要打日志输出实际执行加载的 getClass().getClassLoader()