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

Java双亲委派模型是保障类加载安全性与唯一性的核心机制，通过“先委托父加载器、再自行加载”的层级协作流程，确保JVM核心类（如java.lang.String）不被篡改、避免重复加载，并为系统稳定运行筑起关键防线；尽管在SPI服务加载（如JDBC驱动）、OSGi模块化等场景中会通过线程上下文类加载器或自定义逻辑打破该模型，但其设计思想仍深刻影响着类隔离、热部署和框架扩展等高级实践——理解它，就握住了Java类加载机制的底层逻辑与安全命脉。

双亲委派模型是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学习网公众号！