双亲委派模型确保类加载的安全与唯一，其工作流程为：当类加载请求发起时，先由顶层启动类加载器尝试加载，失败后逐级向下委托，依次由扩展类加载器、应用程序类加载器尝试加载。该机制防止核心类被篡改，避免重复加载，保障系统稳定；典型应用场景包括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免费学习笔记（深入）”；
- 应用程序类加载器接收到加载请求，先不处理，向上委托给扩展类加载器。
- 扩展类加载器收到后，继续向上委托给启动类加载器。
- 启动类加载器尝试加载，如果成功（比如是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源码和实际案例加深理解。
