Java双亲委派模型原理与详解

积累知识，胜过积蓄金银！毕竟在文章开发的过程中，会遇到各种各样的问题，往往都是一些细节知识点还没有掌握好而导致的，因此基础知识点的积累是很重要的。下面本文《Java双亲委派模型详解与原理分析》，就带大家讲解一下知识点，若是你对本文感兴趣，或者是想搞懂其中某个知识点，就请你继续往下看吧~

双亲委派模型确保类加载的安全与唯一，其工作流程为：当类加载请求发起时，先由顶层启动类加载器尝试加载，失败后逐级向下委托，依次由扩展类加载器、应用程序类加载器尝试加载。该机制防止核心类被篡改，避免重复加载，保障系统稳定；典型应用场景包括SPI服务加载（如JDBC）和OSGi模块化框架，这些情况通过线程上下文类加载器或自定义加载逻辑打破双亲委派。

双亲委派模型是Java类加载机制的核心设计之一，理解它有助于掌握类加载的流程和安全性保障机制。简单来说，当一个类加载器收到类加载请求时，它不会自己立即去加载，而是先把请求委派给父类加载器去完成，每一层都如此，直到到达最顶层的启动类加载器（Bootstrap ClassLoader）。只有当父类加载器无法完成加载（比如在指定路径找不到类）时，子类加载器才会尝试自己去加载。

类加载器的层级结构

Java中的类加载器分为三层，构成一个自顶向下的父子关系：

• Bootstrap ClassLoader（启动类加载器）：由C++实现，负责加载JVM核心类库（如java.lang.*），位于rt.jar等核心包中，是所有类加载器的起点。
• Extension ClassLoader（扩展类加载器）：加载jre/lib/ext目录下的类或java.ext.dirs系统变量指定的路径中的类。
• Application ClassLoader（应用程序类加载器）：也叫系统类加载器，负责加载用户类路径（Classpath）上指定的类库，是我们平时写的应用程序默认使用的加载器。

除了这三种，开发者还可以自定义类加载器（继承ClassLoader），它们默认也遵循双亲委派模型。

双亲委派的工作流程

当你的代码调用Class.forName()或创建对象时，JVM会触发类加载过程。具体步骤如下：

• 应用程序类加载器接收到加载请求，先不处理，向上委托给扩展类加载器。
• 扩展类加载器收到后，继续向上委托给启动类加载器。
• 启动类加载器尝试加载，如果成功（比如是java.lang.Object），直接返回结果。
• 如果启动类加载器无法加载（比如不是核心类），则交还给扩展类加载器尝试；若仍失败，再交给应用程序类加载器。
• 最后由应用程序类加载器在Classpath中查找并加载。

这种自底向上检查、自顶向下加载的方式，确保了核心类库的安全性——避免被用户自定义的类“污染”。

为什么需要双亲委派？

它的主要目的有两点：

• 防止重复加载：同一个类不会被多个类加载器重复加载，保证类的唯一性。JVM通过“类全限定名 + 类加载器实例”来确定类的唯一性。
• 保障核心类安全：比如你自己写了一个java.lang.String类，即使放在Classpath中，也不会被加载，因为启动类加载器已经加载了真正的String类，你写的那个会被拒绝。这防止了恶意代码篡改核心类的行为。

打破双亲委派的情况

虽然双亲委派是默认机制，但在某些场景下会被“打破”：

• SPI机制（服务提供接口）：比如JDBC驱动加载。核心类java.sql.Driver在启动类加载器中，但具体的实现（如com.mysql.cj.jdbc.Driver）在应用类路径中。这时需要由线程上下文类加载器（Thread Context ClassLoader）来加载实现类，这就绕过了双亲委派。
• 热部署、模块化框架：OSGi等容器为了实现模块隔离和动态更新，自定义了类加载策略，不再严格遵循双亲委派。

这些情况属于特例，通常通过重写loadClass()方法实现，把加载逻辑控制在特定范围内。

基本上就这些。理解双亲委派模型，关键在于搞清类加载器之间的层级关系和委托顺序。它不仅是Java语言稳健运行的基础，也为后续学习类隔离、模块化、热更新等高级主题打下基础。不复杂但容易忽略细节，建议结合ClassLoader源码和实际案例加深理解。

本篇关于《Java双亲委派模型原理与详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！