1.创建工程1 projectmodule001

2.创建工程2 projectmodule002

3.在常规的java开发中我们是这样做的，在工程1中定义服务接口和服务实现，在工程2中使用工程1提供的服务。

HelloWorldServiceTest.java代码：

package com.white.service.test;import com.white.service.HelloWorld;import com.white.service.impl.HelloWorldServiceImpl;public class HelloWorldServiceTest {	public static void main(String[] args) {		HelloWorld hw = new HelloWorldServiceImpl();		hw.sayHi();	}}

4.说说传统这种做法的弊端：

a.工程1中的类在客户端程序(工程2)中是完全暴露的。

b.要使用工程1中服务提供的方法，必须先要实例化此服务也就是必须去new。

5.spi思想的做法

在工程1下新建目录META-INF文件夹(想了解更多META-INF文件夹信息参考：http://stackoverflow.com/questions/70216/whats-the-purpose-of-meta-inf)在其下面在建一个service文件夹

在com.white.service.HelloWorld文件中添加实现类信息：com.white.service.impl.HelloWorldServiceImpl

然后在客户端程序中通过serviceloader来加载类：

package com.white.service.test;import java.util.Iterator;import java.util.ServiceLoader;import com.white.service.HelloWorld;public class HelloWorldServiceTest {	public static void main(String[] args) {		ServiceLoader
    
      helloWorld = ServiceLoader				.load(HelloWorld.class);		Iterator
     
       it = helloWorld.iterator();		it.next().sayHi();	}}
     
    

相较于传统开发模式，使用spi的好处：

a.客户端程序不用再去new实例，而是通过serviceload去加载类，也就是说责任转移了，原先有客户端负责现在统一由一个叫serviceload的类负责，从设计模式的角度看有点像工厂模式。

b.对于客户端来说服务实现类还是暴露的（也就是说客户端还是可以直接通过传统方式去new，对服务实现没有保护机制）。

6.spi机制实现分析：对于上面spi的功能是怎样实现的呢？让我们来分析一下serviceload类：查了一下中文的api文档对serviceload的解释如下：

=========================================================================

一个简单的服务提供者加载设施。

服务（HelloWorld） 是一个熟知的接口和类（通常为抽象类）集合。服务提供者（HelloWorldServiceImpl） 是服务的特定实现。提供者中的类通常实现接口，并子类化在服务本身中定义的子类。服务提供者可以以扩展的形式安装在 Java 平台的实现中，也就是将 jar 文件放入任意常用的扩展目录中（这句话好像暴露出服务提供者类是由extensions classloader加载的）。也可通过将提供者加入应用程序类路径，或者通过其他某些特定于平台的方式使其可用。

为了加载，服务由单个类型表示，也就是单个接口或抽象类。（可以使用具体类，但建议不要这样做。）一个给定服务的提供者包含一个或多个具体类，这些类扩展了此服务类型，具有特定于提供者的数据和代码。提供者类 通常不是整个提供者本身而是一个代理，它包含足够的信息来决定提供者是否能满足特定请求，还包含可以根据需要创建实际提供者的代码。提供者类的详细信息高度特定于服务；任何单个类或接口都不能统一它们，因此这里没有定义任何这种类型。此设施唯一强制要求的是，提供者类必须具有不带参数的构造方法，以便它们可以在加载中被实例化。

 通过在资源目录 META-INF/services 中放置提供者配置文件 来标识服务提供者。文件名称是服务类型的完全限定。该文件包含一个具体提供者类的完全限定二进制名称列表，每行一个。忽略各名称周围的空格、制表符和空行。注释字符为 '#' ('\u0023', NUMBER SIGN)；忽略每行第一个注释字符后面的所有字符。文件必须使用 UTF-8 编码。

如果在多个配置文件中指定了一个特定的具体提供者类，或在同一配置文件中多次被指定，则忽略重复的指定。指定特定提供者的配置文件不必像提供者本身一样位于同一个 jar 文件或其他的分布式单元中。提供者必须可以从最初为了定位配置文件而查询的类加载器访问；注意，这不一定是实际加载文件的类加载器。

以延迟方式查找和实例化提供者，也就是说根据需要进行。服务加载器维护到目前为止已经加载的提供者缓存。每次调用  方法返回一个迭代器，它首先按照实例化顺序生成缓存的所有元素，然后以延迟方式查找和实例化所有剩余的提供者，依次将每个提供者添加到缓存。可以通过  方法清除缓存。

服务加载器始终在调用者的安全上下文中执行。受信任的系统代码通常应当从特权安全上下文内部调用此类中的方法，以及它们返回的迭代器的方法。

此类的实例用于多个并发线程是不安全的。

除非另有指定，否则将 null 参数传递给此类中的任何方法都会导致抛出 。

示例假定服务类型为 com.example.CodecSet，它用来表示某些协议的编码器/解码器对集合。在这种情况下，它是一个具有两种抽象方法的抽象类：

public abstract Encoder getEncoder(String encodingName);public abstract Decoder getDecoder(String encodingName);

每种方法都返回一个相应的对象；如果提供者不支持给定编码，则返回  null 。典型的提供者支持一种以上的编码。

如果 com.example.impl.StandardCodecs 是 CodecSet 服务的实现，则其 jar 文件还包含一个指定如下的文件：

META-INF/services/com.example.CodecSet

此文件包含一行：

com.example.impl.StandardCodecs    # Standard codecs

CodecSet 类在初始化时创建并保存一个服务实例：

private static ServiceLoader
     
       codecSetLoader= ServiceLoader.load(CodecSet.class);
     

为了查找给定编码名称的编码器，它定义了一个静态工厂方法，该方法迭代所有已知并可用的提供者，只在找到适当的编码器或迭代完提供者时返回。

public static Encoder getEncoder(String encodingName) {for (CodecSet cp :codecSetLoader) {Encoder enc = cp.getEncoder(encodingName);if (enc != null)return enc;     }return null; }

getDecoder 方法的定义类似。

使用注意事项 如果用于提供者加载的类加载器的类路径包含远程网络 URL，则这些 URL 将在搜索提供者配置文件的过程中被取消引用。

此活动是正常的，尽管它可能导致在 Web 服务器日志中创建一些令人迷惑的条目。但是，如果 Web 服务器配置不正确，那么此活动可能导致提供者加载算法意外失败。

如果请求的资源不存在，则 Web 服务器应返回 HTTP 404 (Not Found) 响应。但有时会错误地将 Web 服务器配置为返回 HTTP 200 (OK) 响应，并伴有这种情况下的 HTML 错误帮助页面。这会导致在此类尝试将 HTML 页面作为提供者配置文件进行解析时抛出 。此问题的最佳解决方案是修复配置错误的 Web 服务器，以返回正确的响应代码 (HTTP 404) 以及 HTML 错误页面。

从以下版本开始： 1.6

=========================================================================

关于spi规约说明:

当服务的提供者，提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。 

基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。

jdk提供服务实现查找的一个工具类：java.util.ServiceLoader