为什么 Web 容器要打破双亲委派机制？

一、先把双亲委派讲透

标准的双亲委派规则并不复杂：一个类加载器收到加载请求后，不会立刻自己动手，而是先把请求向上委托给父加载器；父加载器收到请求后同样继续上抛，直到最顶层的启动类加载器。顶层加载器无法完成加载时，请求再逐层向下退回，由收到请求的加载器尝试自己加载。

这套机制的核心收益是类的唯一性：无论从代码的哪个位置触发 java.lang.String 的加载，最终都会由启动类加载器完成，整个进程里不会出现两份 String。这既避免了类型混淆，也防止了核心类库被随意替换带来的安全风险。

整个流程可以用一段简化的伪代码表示：

protected Class<?> loadClass(String name, boolean resolve) {
    synchronized (getClassLoadingLock(name)) {
        Class<?> c = findLoadedClass(name);       // 1. 已加载则直接返回
        if (c == null) {
            try {
                if (parent != null) {
                    c = parent.loadClass(name, false); // 2. 先委托父加载器
                } else {
                    c = findBootstrapClassOrNull(name); // 3. 顶层交给启动类加载器
                }
            } catch (ClassNotFoundException ignored) {
                // 父加载器加载失败，继续向下
            }
            if (c == null) {
                c = findClass(name);                   // 4. 自己尝试加载
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

在单一应用场景下，这套模型工作得很好：依赖版本由构建工具统一管理，类路径在启动时就已确定，不存在同名类冲突的土壤。但一旦进入 Web 容器场景，前提条件就全部改变了。

二、Web 容器带来的新约束

一个 Web 容器往往要同时承载多个相互独立的应用程序。这些应用可能由不同团队开发、在不同时间上线，依赖的第三方库版本也可能彼此冲突。如果仍然严格遵循双亲委派，会出现几类难以回避的问题。

2.1 应用之间必须隔离

假设应用 A 依赖某工具库的 1.x 版本，应用 B 依赖同一工具库的 2.x 版本。在严格双亲委派下，两个应用的类加载请求都会向上汇聚到同一个父加载器，最终同一个类名只能被加载一次，先加载的版本胜出，另一个应用就会在运行时抛出方法缺失或类型不匹配的异常。这类问题在启动阶段往往看不出来，直到某个具体功能被触发才暴露，排查成本极高。

要解决它，就必须允许同名类在不同应用命名空间中共存，也就是让每个应用拥有自己的类加载器，并且优先自己加载，而不是无条件上抛。

2.2 应用需要热部署与热替换

开发与运维过程中，常常需要在不重启整个容器的前提下重新加载某个应用。双亲委派下，类一旦被父加载器加载就长期驻留，无法单独卸载。而 JVM 卸载类的前提是：该类的类加载器不可达。因此，热部署的实现路径只能是为每个应用创建独立的类加载器，替换应用时丢弃旧的类加载器实例，让整个命名空间随之被回收。这天然要求应用类不经过共享的父加载器。

2.3 容器自身类库与应用类库必须分离

容器运行时自身依赖一批类库，应用也会携带自己的依赖。如果完全共享父加载器，应用就可能覆盖容器内部使用的类，导致容器行为异常甚至启动失败。反过来，某些容器内部实现类也不应该直接暴露给应用。合理的做法是：容器类由容器自己的加载器负责，应用类由应用的加载器负责，两者通过明确的边界交互，只共享真正需要共享的基础类。

2.4 共享与隔离需要同时成立

完全隔离并不总是最优。很多场景下，我们希望若干基础类库在多个应用之间共享，以减少内存占用和加载开销；同时又希望业务类严格隔离。这就要求类加载器不是一个简单的两层结构，而是分层、可配置的委派关系：先尝试本地加载，未命中再上抛；同时对特定包名强制走父加载器。

三、打破双亲委派的具体做法

所谓“打破”，并不是彻底废弃委派，而是调整委派的方向与顺序。常见做法是在自定义类加载器中重写 loadClass，采用“先自己、后父级”的顺序：

@Override
protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            // 1. 基础类仍交给父加载器，保证唯一性与安全性
            if (name.startsWith("java.") || name.startsWith("javax.")
                    || name.startsWith("sun.")) {
                c = getParent().loadClass(name);
            } else {
                try {
                    c = findClass(name);          // 2. 优先本地加载
                } catch (ClassNotFoundException e) {
                    c = getParent().loadClass(name); // 3. 本地失败再上抛
                }
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

这段代码体现了三个关键设计点：

• 基础类库强制委派：java.* 等核心包必须由顶层加载器提供，避免核心类型被替换，这是安全底线。
• 业务类优先本地：应用自己的类先由应用加载器查找，保证不同应用之间的同名类互不干扰。
• 失败回退父级：本地找不到时仍然可以复用共享类库，兼顾隔离与共享。

配合这套加载器，容器通常还会维护一份共享类列表，明确哪些包必须由公共加载器加载、哪些必须由应用加载器加载。这份配置本质上就是隔离策略的显式声明。

四、打破之后需要承担的代价

调整委派顺序解决了隔离问题，但也引入了新的复杂度，工程上必须提前评估。

类型转换异常。同一个类被两个不同的加载器加载后，在 JVM 看来就是两个不同的类型。即使全限定名完全一致，互相赋值也会抛出类型转换异常。典型表现是：某个对象由共享加载器创建，却被传给期望应用加载器版本的接口。解决办法是确保接口与传递对象来自同一个加载器，或在边界处做显式适配。

资源泄漏与内存占用。每个应用加载器都持有自己的类元数据与静态字段，应用数量增多时内存压力明显上升。热部署若未正确关闭线程、连接池与定时任务，旧加载器仍被引用而无法回收，就会出现反复部署后内存持续增长的现象。

依赖排查变复杂。类到底由哪个加载器加载，不再能靠直觉判断。排查 ClassNotFoundException 或 NoClassDefFoundError 时，需要打印加载器层级与类的实际来源。可以在启动参数中开启类加载日志，或在关键位置输出 clazz.getClassLoader() 进行确认。

安全边界需要重新审视。优先本地加载意味着应用目录下的类有机会遮蔽同名类。因此核心包的白名单必须严格，且应用可写目录不应包含可被随意替换的核心类路径。

五、实践建议

1. 明确隔离粒度：先确定哪些类必须共享、哪些必须隔离，再据此设计加载器层级，不要一开始就追求完全隔离。
2. 核心包白名单硬编码：java.*、容器自身实现包等必须强制委派，且不可通过配置放开。
3. 控制共享类规模：共享类越多，冲突面越大；只共享确实需要跨应用一致的类型，例如公共接口与基础工具。
4. 重视卸载验证：热部署功能上线前，应做多轮替换压测，观察加载器实例数量与堆内存变化，确认旧加载器确实被回收。
5. 统一异常诊断手段：在框架层提供类来源打印能力，降低排查成本。

六、小结

双亲委派以“向上集中”换取了类的唯一性与安全性，这在单应用场景下是明显划算的。但 Web 容器的本质是多应用共存 + 生命周期独立 + 依赖版本自治，这三个特征与“集中加载”直接冲突。容器打破双亲委派，并非否定这一机制，而是在保留核心类库委派底线的同时，把业务类的加载权下放到应用级加载器，用命名空间隔离换取部署灵活性与故障边界。理解这一取舍，比记住“先自己后父级”的结论更重要——真正决定设计质量的，是对隔离范围与共享范围的精确划分。