前言
最近知识星球中，有位小伙伴问了我一个问题：JDBC为什么会破坏双亲委派机制？
这个问题挺有代表性的。
双亲委派机制是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加载器是平级关系。
不是双亲委派关系。
