Java 双亲委派机制是什么，目的是什么？｜字节跳动后端开发面经解析

60 秒回答模板

双亲委派是类加载器处理加载请求时的一种优先委派规则。某个 ClassLoader 收到加载类的请求后，通常不会立刻自己加载，而是先委托给父加载器；父加载器继续向上委托，直到启动类加载器。只有父加载器无法完成加载时，才逐级向下由子加载器尝试加载。这样做的好处是核心 Java 类会优先由更上层的加载器加载，避免应用自定义同名类替换 JDK 核心类；同时同一个类更容易由同一个加载器加载，减少重复加载和类型不一致问题。需要补充的是，Java 中类的唯一性由类的全限定名和加载它的 ClassLoader 共同决定。

考点 请求先向顶层传递

难度 真实面经高频题

回答目标 讲清机制、边界和追问

深入解析

类加载器的层次关系

Java 中常见类加载器包括启动类加载器、平台类加载器和应用类加载器，业务中还可能有自定义类加载器。这里的“父”通常指加载器之间的委派关系，不一定是普通 Java 对象继承关系。应用类加载器负责加载应用 classpath 下的类，而更上层加载器负责加载更基础、更可信的运行时类库。双亲委派就是围绕这套层次关系建立的加载顺序。

加载请求先向上委派

当一个类加载器收到加载请求时，它一般先检查这个类是否已经被加载过；如果没有，就把请求交给父加载器。父加载器也执行同样流程，直到最顶层加载器。只有父加载器无法找到或加载该类时，请求才会回到子加载器，由子加载器根据自己的搜索路径尝试加载。这个过程避免了每个加载器都直接抢先加载同一个类。

保护核心类库不被替换

双亲委派最重要的目的之一是安全。如果应用自己定义一个与核心类库同名的类，加载请求会先交给上层加载器，核心类会由受信任的加载器优先加载，应用层同名类无法轻易替换标准库实现。这能防止基础 API 被篡改，也保证运行时依赖的核心类型具有稳定、统一的来源。

保证类身份相对一致

在 JVM 中，判断两个类是否相同，不只看全限定名，还要看是否由同一个类加载器加载。两个不同加载器加载的同名类，在 JVM 看来可能是两个不同类型。双亲委派让公共基础类尽量由上层加载器统一加载，从而降低同名类重复加载、类型转换失败和链接冲突的风险，这对大型应用和框架尤其重要。

机制可以被打破但要有理由

双亲委派是默认模型，不是绝对不可改变。某些场景需要打破或调整委派顺序，例如插件隔离、容器隔离、热部署、SPI 服务发现等。典型问题是上层加载器无法反向看到应用类，而一些扩展机制又需要加载应用提供的实现类，因此会借助线程上下文类加载器或自定义加载策略。面试时可以说明：打破委派是为了解决隔离或反向加载需求，但会增加类冲突风险。

易错点

把双亲委派理解成 Java 类继承，而不是类加载器之间的委派关系。
只背“先父后子”，说不出保护核心类库和避免重复加载的目的。
忽略类身份由类名和 ClassLoader 共同决定，无法解释类型转换异常。
认为双亲委派绝对不能破坏，不知道容器、插件和 SPI 场景中的特殊加载需求。

面试官追问

双亲委派中的“父”是继承关系吗？

不是严格意义上的 Java 类继承关系，而是类加载器之间的委派关系。一个加载器收到请求后，会优先把请求委托给它的父加载器处理。

为什么不能让应用类加载器先加载所有类？

如果应用类加载器优先加载，就可能用应用路径下的同名类替换核心类库，带来安全和一致性问题。核心类应由更可信的上层加载器优先加载。

两个同名类一定是同一个类吗？

不一定。JVM 中类的身份由全限定名和加载它的 ClassLoader 共同决定。同名类如果由不同类加载器加载，可能被视为不同类型。

什么时候会打破双亲委派？

插件化、应用容器、热部署、模块隔离、SPI 等场景可能需要特殊加载顺序。打破委派通常是为了隔离不同应用或让上层机制加载下层实现，但要处理类冲突风险。