1、SPI机制

SPI，Service Provider Interface，是JDK内置的一种服务提供发现机制。大致流程：

• 相关组织定义好接口标准并对外提供
• 第三方去针对接口写实现类，并将信息写在META-INF/services/${interface_name}，文件内容是实现类全类名
• 用户使用JDK提供的ServiceLoader加载（jar里的）实现类

写个小Demo直观感受下SPI，定义对外接口：

public interface SpiInterface {void helloSpi();}

其他类写实现类（这里接口和实现类放同一个jar中了，一般来说写接口和写实现的是两种角色）：

public class SpiClass1 implements SpiInterface {@Overridepublic void helloSpi() {System.out.println("hello SpiClass1...");}
}

public class SpiClass2 implements SpiInterface {@Overridepublic void helloSpi() {System.out.println("hello SpiClass2...");}
}

写文件：

//内容
com.plat.impl.SpiClass1
com.plat.impl.SpiClass2

测试模块中引入上面的这个jar:

<dependency><groupId>com.plat</groupId><artifactId>demo</artifactId><version>0.0.1</version>
</dependency>

尝试加载：

public class SpiTest {public static void main(String[] args) {ServiceLoader<SpiInterface> serviceLoader = ServiceLoader.load(SpiInterface.class);for (SpiInterface spiClass : serviceLoader) {System.out.println(spiClass);spiClass.helloSpi();}}
}

成功获取到接口的两个实现类：

2、JDBC案例之SPI机制

JDBC使用DriverManager类来完成不同数据库厂商的驱动注册：

/获取连接
conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/testDB","root","95279527");

DriverManager位于JDK的rt.jar包，由启动类加载器去加载，而引入的第三方jar包归应用程序类加载器管。DriverManager又如何知道jar中要加载哪个驱动类？看下DriverManager类的源码，其中有一段静态代码块：

往下跟进loadInitialDrivers方法：

断点看下值，成功拿到MySQL驱动的类名：

即SPI机制去加载这个接口的实现类，然后用迭代器去遍历所有jar包种满足条件的类名。而MySQL驱动的jar中已按SPI流程写好了实现类和名为java.sql.Driver的文件：

到此，整个JDBC的流程为：

拿到jar包中驱动类的类名了，但这个类得靠应用程序类加载器去加载，那应用程序类加载器从哪儿来？ ⇒ SPI过程能拿到应用程序类加载器，是因为SPI使用了线程上下文中保存的类加载器：

而线程上下文类加载器通常为应用程序类加载器（一个线程创建完之后，JVM底层会将应用程序类加载器放到线程上下文中）：

//获取线程上下文类加载器
ClassLoader c = Thread.currentThread.getContextClassLoader();
//设置线程上下文的类加载器为自定义类加载器
Thread.currentThread().setContextClassLoader(new BreakClassLoader1());
//com.plat.broken.BreakClassLoader1@6537cf78
System.out.println(Thread.currentThread().getContextClassLoader());

ps：对于MySQL的驱动类，其加载过程中会自动注册驱动：

3、打破双亲委派机制：线程上下文类加载器

JDBC案例中，启动类加载器要委托它的下级应用程序类加载器去加载一个类，与双亲委派机制的自下而上委派不符合，因此才说打破了双亲委派机制，但其实这两块都各自满足双亲委派机制，单看DriverManager，其就应该由启动类加载器干，但看Jar中的MySQL驱动类，其也本该由应用程序类加载器干。

4、打破双亲委派机制：osgi模块化

历史上，OSGi模块化框架。它存在同级之间的类加载器的委托加载：

5、JDK9之后的类加载器

JDK8及之前的版本中，扩展类加载器和应用程序类加载器的源码位于rt.jar包中的sun.misc.Launcher.java。

这两个类加载器都继承自URLClassLoader，URLClassLoader是根据某一个特定的目录去找到jar包以及jar包中的字节码文件，所以，JDK8及以前，是按照jar包的位置去加载字节码文件的。JDK9引入了module的概念，之前的包放入到了jmods目录下的jmod文件中，对应的，类加载器也由原来的从jar包中加载改为了去jmod文件中加载：

类加载器的变化：

• 启动类加载器使用Java编写，位于jdk.internal.loader.ClassLoaders类中，但java代码中获取启动类加载器对象依然为null
  

• 扩展类加载器被替换成了平台类加载器（Platform Class Loader），平台类加载器遵循模块化方式加载字节码文件，之前扩展类加载器继承自URLClassLoader，现在继承自BuiltinClassLoader
  

6、小总结