JVM的双亲委派模型
引言
Java类加载机制中的双亲委派模型通过层层委托保证了核心类加载器与应用类加载器之间的职责分离和加载安全性，但其单向的委托关系也带来了一些局限性。尤其是在核心类库需要访问或实例化由应用类加载器加载的类时，双亲委派模型无法满足需求，导致系统类无法直接调用应用类中的实现。为解决这一问题，Java采用了线程上下文类加载器（Context ClassLoader）机制，打破了传统双亲委派的限制，使核心类库能够通过当前线程的上下文类加载器访问应用层的扩展类。典型应用如JDBC中的DriverManager通过服务提供者接口（SPI）机制，利用上下文类加载器动态加载数据库驱动，实现了灵活可扩展的设计。本文将围绕双亲委派模型的不足及其被打破的原因，深入探讨SPI机制及线程上下文类加载器的作用与实现原理。
1. 什么是双亲委派模型？
https://zhuanlan.zhihu.com/p/612318527
https://zhuanlan.zhihu.com/p/612318527
2. 为什么要打破双亲委派模型？
检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个ClassLoader的职责非常明确，但是同时会带来一个问题，即顶层的ClassLoader无法访问底层的ClassLoader所加载的类。
通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
3. SPI是如何打破双亲委派机制的？
由于双亲委派模型的限制，父加载器无法访问由子加载器加载的类，所以核心类库无法直接访问这些SPI实现类。当核心类库需要调用SPI实现时，它会通过Thread.currentThread().getContextClassLoader()获取当前线程的上下文类加载器，从而可以访问到应用层的实现类。
DriverManager是JDBC里管理和注册不同数据库Driver的工具类。在使用Java JDBC进行数据库编程时，我们引入驱动包之后，直接使用Connection connection = DriverManager.getConnection(url,user,password);便可以成功获得数据库连接。
- 启动类加载器加载DriverManager。
- DriverManager.getConnection时，通过SPI机制加载jar包中的mysql驱动。
- SPI中利用了线程上下文类加载器（应用程序类加载器）去加载类并创建对象。
4. SPI机制
- 需要先定义一个接口，作为扩展的标准。
- 在 classpath 目录下创建 META-INF/service 文件目录。
- 在这个目录下，创建以接口的全限定名命名的配置文件，文件内容是这个接口的实现类。
- 在应用程序里面，使用 ServiceLoad.load()，就可以根据接口名称找到 classpath 所有的扩展类。
感谢您的阅读！如果文章中有任何问题或不足之处，欢迎及时指出，您的反馈将帮助我不断改进与完善。期待与您共同探讨技术，共同进步！