一、前言

双亲委派模型是Java类加载器的核心设计，它保证了核心类的安全性，但也存在天然的缺陷——父类加载器无法访问子类加载器加载的类。这个缺陷在SPI（服务提供者接口）场景下会直接导致程序无法运行，比如我们常用的JDBC，就必须打破双亲委派才能正常工作。

---

二、先回顾：什么是双亲委派模型？

双亲委派是Java类加载器的核心规则，核心逻辑：

子类加载器先把加载请求交给父类加载器，父类加载器能加载就父类加载，父类加载不了，才轮到子类自己加载

类加载器的层级结构（从上到下）

• Bootstrap ClassLoader（启动类加载器）：最顶层，加载JDK/lib下的核心类（如java.lang.*、java.sql.*），C++实现，非Java类。
• Extension ClassLoader（扩展类加载器）：加载JDK/lib/ext下的扩展类。
• Application ClassLoader（应用类加载器）：加载用户代码、第三方jar包（如MySQL JDBC驱动）。
• 自定义类加载器：用户自定义的加载器，父加载器默认是应用类加载器。

双亲委派的核心特点

• 单向可见性：子类加载器可以访问父类加载器加载的类，但父类加载器完全无法访问子类加载器加载的类（类似继承关系：子类能继承父类属性，父类不能用子类属性）。
• 安全优先：防止核心类被篡改（如自定义java.lang.String永远不会被加载）。

自定义类加载器的基础规则

自定义类加载器时，需要继承 java.lang.ClassLoader 类：

• 如果不想打破双亲委派模型，那么只需要重写 findClass 方法即可；
• 如果想打破双亲委派模型，则需要重写 loadClass 方法。

---

三、双亲委派的致命缺点：SPI场景无法工作

1. 什么是SPI？

SPI全称 Service Provider Interface，是Java的服务提供者接口机制：

• 接口定义：由Java核心类库提供（java.*包下，Bootstrap ClassLoader加载）。
• 实现类：由第三方厂商提供（第三方jar包，应用类加载器/自定义加载器加载）。

最经典的例子就是JDBC：

• 接口：java.sql.Driver（Java核心类，Bootstrap加载）
• 实现：com.mysql.cj.jdbc.Driver（MySQL JDBC驱动，第三方jar，应用类加载器加载）

2. 用双亲委派加载JDBC，会发生什么？

我们模拟正常的JDBC加载流程：

1. 用户代码执行Class.forName("com.mysql.cj.jdbc.Driver")，由应用类加载器加载MySQL驱动，注册到DriverManager。
2. 执行DriverManager.getConnection()，DriverManager是Java核心类，由Bootstrap ClassLoader加载。
3. DriverManager需要遍历所有注册的Driver实现，找到MySQL的com.mysql.cj.jdbc.Driver。

🔴 致命问题：
DriverManager由Bootstrap（顶层父加载器）加载，根据双亲委派的「单向可见性」：
父加载器无法访问子类加载器加载的类
DriverManager根本找不到com.mysql.cj.jdbc.Driver，直接报ClassNotFoundException。

---

四、解决方案：打破双亲委派模型

要解决双亲委派的单向限制问题，让父加载器能访问子类加载器的类，Java提供了两种核心打破方法：

方法1：重写 loadClass() 方法

双亲委派的完整逻辑，都是在 loadClass() 方法中实现的。因此要破坏这种机制，只需要自定义一个类加载器，继承 ClassLoader 并重写 loadClass() 方法，使其不执行双亲委派的委托逻辑即可。

这种方式适合需要完全自定义类加载顺序、实现类隔离的场景（如Tomcat的WebAppClassLoader）。

方法2：利用线程上下文加载器

利用线程上下文类加载器（Thread Context ClassLoader），是Java官方提供的、最常用的打破双亲委派的方案，也是SPI场景的标准解决方案。

Java应用的上下文加载器默认使用 AppClassLoader（应用类加载器）。若想要在父类加载器中使用到子类加载器加载的类，可以通过以下代码获取：

Thread.currentThread().getContextClassLoader()

通过这种方式，顶层的Bootstrap ClassLoader可以主动获取到应用类加载器，用子类加载器加载第三方实现类，完美解决SPI场景的加载问题。

JDBC的真实加载流程（打破双亲委派）

1. DriverManager（Bootstrap加载）调用Thread.currentThread().getContextClassLoader()，拿到应用类加载器。
2. 用应用类加载器加载META-INF/services/java.sql.Driver中配置的第三方驱动（如MySQL的com.mysql.cj.jdbc.Driver）。
3. 成功加载驱动类，完成数据库连接。

其他打破双亲委派的场景

• Tomcat等Web容器：同一Tomcat部署多个Web应用，每个应用用独立类加载器，实现类隔离，避免冲突。
• OSGi模块化：动态加载、卸载模块，需要自定义类加载顺序。
• 热部署工具（如JRebel）：重新加载类，绕过双亲委派的缓存机制。

---

五、面试必背知识点总结

1. 双亲委派的缺点

• 单向可见性限制：父类加载器无法访问子类加载器加载的类，导致SPI场景（接口核心加载、实现第三方加载）无法正常工作。
• 无法适配动态加载需求：Tomcat、OSGi等需要类隔离、动态加载的场景，无法适配双亲委派的层级结构。

2. 自定义类加载器的核心规则

需求	需要重写的方法	是否遵循双亲委派
仅自定义类加载逻辑	findClass	✅ 是
打破双亲委派模型	loadClass	❌ 否

3. SPI场景的核心问题（JDBC为例）

组件	类加载器	核心矛盾
java.sql.Driver（接口）	Bootstrap ClassLoader	核心类，顶层加载
com.mysql.cj.jdbc.Driver（实现）	应用类加载器	第三方jar，子类加载
DriverManager（工具类）	Bootstrap ClassLoader	父加载器找不到子类加载的实现类

4. 打破双亲委派的两种核心方法

方法	原理	适用场景
重写 loadClass() 方法	绕过双亲委派的委托逻辑，自定义加载顺序	Tomcat、OSGi等需要类隔离的场景
线程上下文类加载器	父加载器主动获取子类加载器，加载第三方类	JDBC等SPI服务场景

---

六、常见误区&避坑

误区	正确结论
双亲委派是Java强制规则，不能打破	❌ 是推荐规范，非强制，SPI、Tomcat等场景主动打破
SPI实现类由Bootstrap加载	❌ 实现类是第三方jar，由应用类加载器加载
线程上下文类加载器默认是Bootstrap	❌ 默认是应用类加载器
打破双亲委派会导致安全问题	❌ 正常使用（如SPI）安全，仅恶意篡改核心类有风险
自定义类加载器必须重写loadClass	❌ 仅需打破双亲委派时重写，否则重写findClass即可

---

七、总结

双亲委派是Java类加载的核心设计，它用单向可见性保证了核心类的安全，但也限制了SPI等动态扩展场景的使用。

Java通过线程上下文类加载器和重写loadClass方法两种方案，完美打破了双亲委派的限制，解决了SPI的加载问题，这也是我们日常使用JDBC等工具的底层原理。

同时要记住自定义类加载器的核心规则：保双亲委派重写findClass，破双亲委派重写loadClass，掌握这个知识点，不仅能理解JDBC的工作原理，也能轻松应对面试中的类加载相关考点。