摘要：作为 Java 开发，你是不是也遇到过这种情况：面试时被问到 “什么是双亲委派机制”，只能磕磕绊绊说出 “父加载器先加载，父加载器加载不了子加载器再加载”，可面试官一追问 “为什么要设计双亲委派机制”“怎么打破双亲委派”，就瞬间大脑空白？其实不是你记性差，而是
作为 Java 开发，你是不是也遇到过这种情况：面试时被问到 “什么是双亲委派机制”，只能磕磕绊绊说出 “父加载器先加载，父加载器加载不了子加载器再加载”，可面试官一追问 “为什么要设计双亲委派机制”“怎么打破双亲委派”，就瞬间大脑空白？其实不是你记性差，而是没从 “原理 + 场景” 的角度把这个知识点吃透。今天这篇文，就用你能听懂的大白话，把 Java 类加载的双亲委派机制拆得明明白白，从面试高频问题到实战场景，帮你一次掌握。
我见过不少开发同行，准备 Java 面试时总觉得 “双亲委派就是个基础概念，背背定义就行”，可一到现场就被面试官问住。比如这些高频问题，你可以先自测下：
“如果我自定义一个 java.lang.String 类，能被 JVM 加载吗？为什么？”
“双亲委派机制里，‘双亲’指的是父加载器和祖父加载器吗？还是其他关系？”
“Tomcat 为什么要打破双亲委派机制？具体是怎么实现的？”
“类加载器加载类的流程里，双亲委派是在哪个环节起作用的？”
是不是发现，只背定义根本应付不了这些追问？其实面试官问双亲委派，不是考你 “会不会背概念”，而是看你 “懂不懂原理、能不能结合实际场景分析”—— 毕竟实际开发中，类加载异常、框架底层的类加载逻辑，都和双亲委派息息相关。要是只停留在 “表面记忆”，不仅面试过不了，遇到相关问题也没法排查。
要理解双亲委派，得先知道它的 “生存土壤”——Java 的类加载机制。你写的 Java 代码，会先编译成.class 字节码文件，可 JVM 并不能直接识别字节码，得通过 “类加载器” 把这些字节码加载到内存里，转换成可执行的 Class 对象，这个过程就是类加载。
那为什么需要 “双亲委派” 这种规则呢？这得从 Java 的设计目标说起。Java 诞生时的核心需求之一是 “跨平台”，而类加载器就是实现 “一次编写、到处运行” 的关键环节 —— 不同操作系统的类加载器，要保证加载的类是 “统一、安全” 的。比如你在 Windows 上写的 String 类，和在 Linux 上加载的 String 类，必须是同一个类，否则会出现 “类不兼容” 问题；同时，也得防止有人恶意自定义一个 java.lang.String 类，替换掉 JDK 自带的 String 类，引发安全风险。
简单说，类加载机制是 JVM 运行的 “入口”，而双亲委派机制，就是给这个 “入口” 加的 “安全锁” 和 “统一规则”—— 既保证类的唯一性，又防止恶意类篡改，这也是面试官为什么总揪着这个知识点不放的原因：它是理解 JVM 类加载逻辑的基础，也是排查类加载问题的关键。
接下来进入重点：双亲委派机制到底是怎么运作的？我用 “流程 + 案例” 的方式给你拆解，看完你就能直接套用在面试里。
在 Java 中，默认有 4 种核心类加载器，它们的 “父子关系”（注意不是继承关系，而是委派关系）是双亲委派的基础，你得先记清：
启动类加载器（Bootstrap ClassLoader）：最顶层的加载器，由 C++ 实现，负责加载 JDK 核心类库（比如 java.lang 包下的类），加载路径是 JRE/lib 下的 rt.jar 等文件。你在代码里打印它的.getClass .getName ，会返回 null，因为它不是 Java 类。扩展类加载器（Extension ClassLoader）：由 Java 实现，负责加载 JRE/lib/ext 目录下的扩展类库，比如一些第三方提供的扩展 jar 包。它的 “父加载器” 是启动类加载器。应用程序类加载器（Application ClassLoader）：也叫系统类加载器，负责加载你写的应用程序代码（比如 src/main/java 下的类），以及 classpath 环境变量指定的类库。它的 “父加载器” 是扩展类加载器。自定义类加载器（Custom ClassLoader）：如果你有特殊需求（比如加载加密的.class 文件、从网络加载类），可以继承 ClassLoader 类实现自定义加载器，它的 “父加载器” 默认是应用程序类加载器。这里要注意：面试官常挖的坑是 “双亲委派的‘双亲’指什么？”—— 不是父加载器 + 祖父加载器，而是 “当前类加载器先委派给父加载器，父加载器再委派给祖父加载器”，直到顶层的启动类加载器，这是一种 “向上委派、向下加载” 的逻辑。
我用 “加载一个自定义的 com.test.User 类” 为例，带你看双亲委派的完整流程，你记下来面试时直接说，面试官会觉得你理解得很透彻：
第一步：应用程序类加载器收到 “加载 com.test.User” 的请求，它不会先自己加载，而是先把请求委派给它的父加载器 —— 扩展类加载器；
第二步：扩展类加载器收到请求后，也不会自己加载，继续把请求委派给它的父加载器 —— 启动类加载器；
第三步：启动类加载器收到请求后，会检查自己的加载范围（JRE/lib 下的核心类库）—— 发现没有 com.test.User 类，于是告诉扩展类加载器 “我加载不了”；
第四步：扩展类加载器收到反馈后，检查自己的加载范围（JRE/lib/ext）—— 也没有 com.test.User 类，再告诉应用程序类加载器 “我也加载不了”；
第五步：应用程序类加载器收到反馈后，才会自己去加载 com.test.User 类，如果能找到对应的.class 文件，就加载成 Class 对象；如果找不到，就抛出 ClassNotFoundException。
简单总结就是：“先向上委派，父加载器能加载就加载，父加载器加载不了，子加载器再自己加载”。这就是双亲委派的核心逻辑，你用这个流程 + 例子回答，比干背定义清晰多了。
面试官问完流程，肯定会追问 “双亲委派的作用是什么？”，你别只说 “保证安全”，要分点说清楚，结合场景更有说服力：
作用 1：防止类重复加载，保证类的唯一性。比如你自定义了一个 java.lang.String 类，如果没有双亲委派，应用程序类加载器会加载你写的 String 类，而启动类加载器也会加载 JDK 自带的 String 类，这样 JVM 里就有两个 String 类，会导致 “类 cast 异常” 等问题。有了双亲委派，请求会先委派到启动类加载器，启动类加载器已经加载了 JDK 的 String 类，就不会再让子加载器加载自定义的 String 类，保证了类的唯一性。作用 2：保护核心类库，防止恶意篡改。还是拿 java.lang.String 举例，如果你想恶意修改 String 的 equals 方法，让它返回错误结果，即便你写了 java.lang.String 类，双亲委派机制会让请求先到启动类加载器 —— 启动类加载器只会加载 JDK 自带的 String 类，不会加载你自定义的恶意类，这样就保护了核心类库的安全。作用 3：实现类加载的层级统一。不同的类加载器加载不同范围的类，双亲委派让类加载有了 “优先级”—— 核心类库由顶层加载器加载，应用类由底层加载器加载，避免了 “同一个类被不同加载器加载” 的混乱，也为后续的类卸载、模块化加载（比如 Java 9 的模块系统）打下基础。如果你能答到这里，面试官已经对你有好感了，但要拿高分，还得会答 “打破双亲委派” 的问题 —— 因为实际框架里很多场景需要打破，比如 Tomcat、Spring，这能体现你的实战经验。
双亲委派的核心是 “向上委派”，而 “打破” 就是指：某些场景下，子加载器不先委派父加载器，而是自己直接加载类，或者父加载器委托子加载器加载类。
为什么要打破？因为双亲委派的 “严格层级” 在某些场景下会受限。比如 Tomcat 作为 Web 服务器，要部署多个 Web 应用，每个 Web 应用可能用不同版本的 Spring、MySQL 驱动 —— 如果按双亲委派，这些类会由应用程序类加载器统一加载，一旦版本不同，就会出现 “类冲突”（比如 Spring 5 和 Spring 6 的类不兼容）。所以 Tomcat 会为每个 Web 应用创建一个 “WebApp 类加载器”，让每个应用加载自己的类，这就是打破双亲委派。
你不用记太多，掌握这 3 种常见方式，结合例子说就行：
方式 1：重写 ClassLoader 的 loadClass 方法。双亲委派的逻辑是在 loadClass 方法里实现的 —— 默认流程是 “先委派父加载器，父加载器加载不了再自己加载”。如果重写 loadClass 方法，去掉 “向上委派” 的逻辑，直接调用 findClass 方法加载类，就能打破双亲委派。比如早期的 JDBC 驱动，就是通过这种方式打破的（不过现在已经用 SPI 机制了）。方式 2：使用 Thread.getContextClassLoader 。Java 线程有一个 “上下文类加载器”，默认是应用程序类加载器。有些框架（比如 Spring）需要加载不同层级的类 —— 比如 Spring 要加载 JDK 核心类（由启动类加载器加载）和应用类（由应用程序类加载器加载），但启动类加载器无法委派给子加载器，这时 Spring 就会通过 Thread.getContextClassLoader 获取应用程序类加载器，去加载应用类，间接打破了双亲委派。方式 3：使用 SPI（服务提供者接口）机制。JDK 的 SPI 机制（比如 JDBC、JCE）也会打破双亲委派。比如 JDBC 的 Driver 接口在 rt.jar 里（由启动类加载器加载），但具体的 Driver 实现类（比如 MySQL 的 com.mysql.cj.jdbc.Driver）在第三方 jar 里（由应用程序类加载器加载）。启动类加载器加载 Driver 接口后，需要加载实现类，但按双亲委派，启动类加载器不能委派给子加载器，这时就会通过 SPI 机制，用上下文类加载器加载实现类，打破双亲委派。最后帮你梳理下，面试时遇到 “双亲委派机制” 的问题，按这个逻辑答，绝对不会错：
先定义：双亲委派是 Java 类加载器的一种规则，子加载器加载类前，先委派父加载器加载，父加载器加载不了再自己加载；说流程：结合 4 种类加载器的层级，用 “加载自定义类” 的例子，讲清楚 “向上委派、向下加载” 的步骤；讲作用：分 3 点说 “保证类唯一性、保护核心类库、实现层级统一”，结合 “自定义 java.lang.String 类” 的例子；延伸场景：说说 “为什么要打破”（比如 Tomcat 多应用部署），举 1-2 个打破方式（比如重写 loadClass 、SPI 机制）。另外，我建议你看完这篇文后，自己动手做个小实验：写一个自定义类加载器，重写 loadClass 方法打破双亲委派，再试试加载一个自定义的 java.lang.String 类 —— 你会发现，即便写了这个类，JVM 还是会加载 JDK 自带的 String 类，这能帮你更直观地理解双亲委派的 “安全保护” 作用。
如果面试时面试官问你 “有没有实践过类加载相关的场景”，你把这个实验说出来，会比只背理论加分很多。最后，如果你在实际操作中遇到问题，或者想补充其他 Java 面试知识点，随时回来讨论，咱们一起把技术面试吃透！
来源：从程序员到架构师