java spi与dubbo spi区别

java spi

java spi是上游产商给服务供应商提供的接口，供应商遵循接口契约提供自己的实现.。提供了服务接口的一种实现之后，在jar包的META-INF/services/目录里同时创建一个以服务接口命名的文件。该文件里就是实现该服务接口的具体实现类。而当外部程序装配这个模块的时候，就能通过该jar包META-INF/services/里的配置文件找到具体的实现类名，并装载实例化，完成模块的注入。 基于这样一个约定就能很好的找到服务接口的实现类，而不需要再代码里制定。简单来讲就是为某个接口寻找服务实现的机制。

package search;  
  
import java.util.Iterator;  
import java.util.ServiceLoader;  
  
public class SearchTest {  
  
    public static void main(String[] args) {  
        ServiceLoader<Search> s = ServiceLoader.load(Search.class);  
        Iterator<Search> searchs = s.iterator();  
        if (searchs.hasNext()) {  
            Search curSearch = searchs.next();  
            curSearch.search("test");  
        }  
    }  
}  

dubbo spi

dubbo的扩展点加载从JDK标准的SPI(Service Provider Interface)扩展点发现机制加强而来。
当接口上打了该注解时，dubbo会在META-INF/dubbo/internal/接口全名文件下读取扩展点.配置文件内容为name->implementation class，可以声明多个提供者,dubbo spi主要实现是在ExtensionLoader类中
如下图：

dubbo spi中常用的几个注解：

1. @Spi:默认拓展实现类
2. @Adaptive:自适应拓展实现类标志
3. @Activate：自动激活条件的标记

两者区别：

1. JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
2. 增加了对扩展点 IoC 和 AOP 的支持，一个扩展点可以直接 setter 注入其它扩展点。
3. 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果 RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和 ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。