我们日常经常讨论的虚拟机加载类的机制长这样。
但是我们今天谈论的是整个加载机制的一部分。对于常见的java虚拟机，加载类是一个非常重要的过程，我们常见的类加载方式采用的是双亲委托机制来加载类，针对整个工程编译后的.class文件进行加载（java虚拟机加载的类资源不仅仅局限于本地文件也可以加载远程的网络中的资源）在整个加载过程中保证了，虚拟机的核心类库的类可以准确且正确的加载并对外提供功能，但是也不能满足所有的场景。在双亲委托机制之外提供了一些机制来满足需要扩展的功能，做为对双亲委托机制的有效补充部分，比如spi机制。
spi 机制是为了满足一些服务的服务而定向提供的接口。一般和 KPI搭配使用。满足整个完整的功能。在日常开发过程中，一些需要对外提供综合性功能的api 的内部实现涉及到不同平台，每个平台可能有不同的标准。比如一些企业级开发需要满足 jdni 机制，来提供应用程序所需要资源上命名与目录服务，（比如常见的jdbc 连接需要满足不同的瞬狙库驱动）这个时候针对不同的环境需要作出不同的适应性改造来封装环境影响因素显得很有必要，一方面降低了开发难度。另一方面可以提供更加丰富的功能。在jdk的设计的时候也比较常见，比如在nio 操作的时候 通过屏蔽不同操作平台的网络交互模型。将这些影响因素隔离在和具体平台管理类相关的加载过程中 ，对调用层保持一定的透明性从而降低整个开发难度。
所以双亲委托机制处在整个类加载的核心位置，spi 机制也作为补充机制。共同完善整个加载机制。
