⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处苏三说技术「苏三」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

前言

双亲委派机制是Java中非常重要的类加载机制，它保证了类加载的完整性和安全性，避免了类的重复加载。

这篇文章就跟大家一起聊聊，Java中类加载的双亲委派机制到底是怎么回事，有哪些破坏双亲委派机制的案例，为什么要破坏双亲委派机制，希望对你会有所帮助。

1 为什么要双亲委派机制？

我们的Java在运行之前，首先需要把Java代码转换成字节码，即class文件。

然后JVM需要把字节码通过一定的方式加载到内存中的运行时数据区。

这种方式就是类加载器（ClassLoader）。

再通过加载、验证、准备、解析、初始化这几个步骤完成类加载过程，然后再由jvm执行引擎的解释器和JIT即时编译器去将字节码指令转换为本地机器指令进行执行。

我们在使用类加载器加载类的时候，会面临下面几个问题：

如何保证类不会被重复加载？类重复加载会出现很多问题。
类加载器是否允许用户自定义？
如果允许用户自定义，如何保证类文件的安全性？
如何保证加载的类的完整性？

为了解决上面的这一系列的问题，我们必须要引入某一套机制，这套机制就是：双亲委派机制。

2 什么是双亲委派机制？

接下来，我们看看什么是双亲委派机制。

双亲委派机制的基本思想是：当一个类加载器试图加载某个类时，它会先委托给其父类加载器，如果父类加载器无法加载，再由当前类加载器自己进行加载。

这种层层委派的方式有助于保障类的唯一性，避免类的重复加载，并提高系统的安全性和稳定性。

在Java中默认的类加载器有3层：

启动类加载器（Bootstrap Class Loader）：负责加载 %JAVA_HOME%/jre/lib 目录下的核心Java类库，比如：rt.jar、charsets.jar等。它是最顶层的类加载器，通常由C++编写。
扩展类加载器（Extension Class Loader）：负责加载Java的扩展库，一般位于<JAVA_HOME>/lib/ext目录下。
应用程序类加载器（Application Class Loader）：也称为系统类加载器，负责加载用户类路径（ClassPath）下的应用程序类。

用一张图梳理一下，双亲委派机制中的3种类加载器的层次关系：

但这样不够灵活，用户没法控制，加载自己想要的一些类。

于是，Java中引入了自定义类加载器。

创建一个新的类并继承ClassLoader类，然后重写findClass方法。

该方法主要是实现从那个路径读取 ar包或者.class文件，将读取到的文件用字节数组来存储，然后可以使用父类的defineClass来转换成字节码。

如果想破坏双亲委派的话，就重写loadClass方法，否则不用重写。

类加载器的层次关系改成：

双亲委派机制流程图如下：

具体流程大概是这样的：

需要加载某个类时，先检查自定义类加载器是否加载过，如果已经加载过，则直接返回。
如果自定义类加载器没有加载过，则检查应用程序类加载器是否加载过，如果已经加载过，则直接返回。
如果应用程序类加载器没有加载过，则检查扩展类加载器是否加载过，如果已经加载过，则直接返回。
如果扩展类加载器没有加载过，则检查启动类加载器是否加载过，如果已经加载过，则直接返回。
如果启动类加载器没有加载过，则判断当前类加载器能否加载这个类，如果能加载，则加载该类，然后返回。
如果启动类加载器不能加载该类，则交给扩展类加载器。扩展类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。
如果扩展类加载器不能加载该类，则交给应用程序类加载器。应用程序类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。
如果应用程序类加载器不能加载该类，则交给自定义类加载器。自定义类加载器判断能否加载这个类，如果能加载，则加载该类，然后返回。
如果自定义类加载器，也无法加载这个类，则直接抛ClassNotFoundException异常。

这样做的好处是：

保证类不会重复加载。加载类的过程中，会向上问一下是否加载过，如果已经加载了，则不会再加载，这样可以保证一个类只会被加载一次。
保证类的安全性。核心的类已经被启动类加载器加载了，后面即使有人篡改了该类，也不会再加载了，防止了一些有危害的代码的植入。

3 破坏双亲委派机制的场景

既然Java中引入了双亲委派机制，为什么要破坏它呢？

答：因为它有一些缺点。

下面给大家列举一下，破坏双亲委派机制最常见的场景。

3.1 JNDI

JNDI是Java中的标准服务，它的代码由启动类加载器去加载。

但JNDI要对资源进行集中管理和查找，它需要调用由独立厂商在应用程序的ClassPath下的实现了JNDI接口的代码，但启动类加载器不可能“认识”这些外部代码。

为了解决这个问题，Java后来引入了线程上下文类加载器（Thread Context ClassLoader）。

这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置。

如果创建线程时没有设置，他将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。

有了线程上下文加载器，JNDI服务就可以使用它去加载所需要的SPI代码，也就是父类加载器请求子类加载器去完成类加载的动作，这样就打破了双亲委派机制。

3.2 JDBC

原生的JDBC中Driver驱动本身只是一个接口，并没有具体的实现，具体的实现是由不同数据库类型去实现的。

例如，MySQL的mysql-connector.jar中的Driver类具体实现的。

原生的JDBC中的类是放在rt.jar包，是由启动类加载器进行类加载的。

在JDBC中需要动态去加载不同数据库类型的Driver实现类，而mysql-connector.jar中的Driver实现类是用户自己写的代码，启动类加载器肯定是不能加载的，那就需要由应用程序启动类去进行类加载。

为了解决这个问题，也可以使用线程上下文类加载器（Thread Context ClassLoader）。

3.3 Tomcat容器

Tomcat是Servlet容器，它负责加载Servlet相关的jar包。

此外，Tomcat本身也是Java程序，也需要加载自身的类和一些依赖jar包。

这样就会带来下面的问题：

一个Tomcat容器下面，可以部署多个基于Servlet的Web应用，但如果这些Web应用下有同名的Servlet类，又不能产生冲突，需要相互独立加载和运行才行。
但如果多个Web应用，使用了相同的依赖，比如：SpringBoot、Mybatis等。这些依赖包所涉及的文件非常多，如果全部都独立，可能会导致JVM内存不足。也就是说，有些公共的依赖包，最好能够只加载一次。
我们还需要将Tomcat本身的类，跟Web应用的类隔离开。

这些原因导致，Tomcat没有办法使用传统的双亲委派机制加载类了。

那么，Tomcat加载类的机制是怎么样的？

CommonClassLoader：是Tomcat最基本的类加载器，它加载的类可以被Tomcat容器和Web应用访问。
CatalinaClassLoader：是Tomcat容器私有的类加载器，加载类对于Web应用不可见。
SharedClassLoader：各个Web应用共享的类加载器，加载的类对于所有Web应用可见，但是对于Tomcat容器不可见。
WebAppClassLoader：各个Web应用私有的类加载器，加载类只对当前Web应用可见。比如不同war包应用引入了不同的Spring版本，这样能加载各自的Spring版本，相互隔离。

3.4 热部署

由于用户对程序动态性的追求，比如：代码热部署、代码热替换等功能，引入了OSGi（Open Service Gateway Initiative）。

OSGi中的每一个模块（称为Bundle）。

当程序升级或者更新时，可以只停用、重新安装然后启动程序的其中一部分，对企业来说这是一个非常诱人的功能。

OSGi的Bundle类加载器之间只有规则，没有固定的委派关系。

各个Bundle加载器是平级关系。

不是双亲委派关系。

芋道源码 —— 纯源码解析博客

秒懂双亲委派机制

前言