（JVM）破坏双亲委派模型。

双亲委派模型很好地解决了各个类加载器的基础类统一问题（越是基础的类越由上层加载器加载），基础类被其他的对象锁调用，但是如果基础类需要加载调回其他用户的代码的时候模型便会被破坏。

SPI机制简介
SPI的全名为Service Provider Interface，主要是应用于厂商自定义组件或插件中。在java.util.ServiceLoader的文档里有比较详细的介绍。简单的总结下java SPI机制的思想：我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块、xml解析模块、jdbc模块等方案。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 Java SPI就是提供这样的一个机制：为某个接口寻找服务实现的机制。有点类似IOC的思想，就是将装配的控制权移到程序之外，在模块化设计中这个机制尤其重要。
SPI具体约定
Java SPI的具体约定为：当服务的提供者提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。jdk提供服务实现查找的一个工具类：java.util.ServiceLoader。

对于SPI的解释便是在 应用程序调用数据库的时候，对于不同的数据库采用不同的JAR包，加载不同的驱动。

对于SPI的一个应用的目录结构如图所示：

其中每个里面的代码为：
HelloInterface

package com.jhc.spi;

public interface HelloInterface {
	public void sayHello();
}

SPIMain

package com.jhc.spi;
/**
 *JAVA SPI机制我们可以不修改Jar包或者框架就能够为API提供新实现
 */
import java.util.ServiceLoader;

public class SPIMain {
	public static void main(String[] args){
		ServiceLoader loaders = ServiceLoader.load(HelloInterface.class);
		for(HelloInterface h : loaders){
			h.sayHello();
		}
		
	}
}

ImageHello

package com.jhc.spi;
/**
 *JAVA SPI机制我们可以不修改Jar包或者框架就能够为API提供新实现
 */
import java.util.ServiceLoader;

public class SPIMain {
	public static void main(String[] args){
		ServiceLoader loaders = ServiceLoader.load(HelloInterface.class);
		for(HelloInterface h : loaders){
			h.sayHello();
		}
		
	}
}

TextHello

package com.jhc.spi.impl;

import com.jhc.spi.HelloInterface;

public class TextHello implements HelloInterface{
	public void sayHello(){
		System.out.println("Text sayHello");
	}
}

com.jhc.spi.HelloInterface

com.jhc.spi.impl.ImageHello
com.jhc.spi.impl.TextHello

输出的结果：

对于SPI最大优点在于，在我们的应用程序中可以采取，面向接口编程而在需要实现的地方，提供几种不同的实现方式。
只需要在META/service/com.jhc.spi.HelloInterface 文件中把想要应用的接口的位置声明便可以。

而其破坏双亲委派模型的地方在于：
ServiceLoader这个类只能由BoostrapClassLoader这个最顶层的类加载器加载，而对于想要应用的类HelloInterface.class这个类却需要用到ApplicationClassLoader这个类去实现，这就违反双亲委派模型当中只能委派给父类加载的模型。
这里提出了一个线程上下文类加载器：Thread.currentThread().getContextClassLoader();得到这个线程上下文的类加载器

ServiceLoader loaders = ServiceLoader.load(HelloInterface.class);
然后在load里面的代码
	public static  ServiceLoader load(Class service) {
	        ClassLoader cl = Thread.currentThread().getContextClassLoader();
	        return ServiceLoader.load(service, cl);
	  }
得到当前的上下文ClassLoader，默认的是ApplicationClassLoader()，然后这样在同一个线程里面就会得到这个ClassLoader()
	   public static  ServiceLoader load(Class service,
	                                            ClassLoader loader)
	    {
	        return new ServiceLoader<>(service, loader);
	    }
 private ServiceLoader(Class svc, ClassLoader cl) {
        service = Objects.requireNonNull(svc, "Service interface cannot be null");
        loader = (cl == null) ? ClassLoader.getSystemClassLoader() : cl;
        acc = (System.getSecurityManager() != null) ? AccessController.getContext() : null;
        reload();
    }