详解java实践SPI机制及浅析源码

1.概念

正式步入今天的核心内容之前，溪源先给大家介绍一下关于SPI机制的相关概念，最后会提供实践源代码。

SPI即Service Provider Interface，属于JDK内置的一种动态的服务提供发现机制，可以理解为运行时动态加载接口的实现类。更甚至，大家可以将SPI机制与设计模式中的策略模式建立联系。

SPI机制：

从上图中理解SPI机制：标准化接口+策略模式+配置文件；

SPI机制核心思想：系统设计的各个抽象，往往有很多不同的实现方案，在面向的对象的设计里，一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制

使用场景：

1.数据库驱动加载：面对不同厂商的数据库，JDBC需要加载不同类型的数据库驱动； 2.日志接口实现：SLF4J加载不同日志实现类； 3.溪源在实际开发中也使用了SPI机制：面对不同仪器平台的结果文件上传需要解析具体的结果，文件不同，解析逻辑不同，因此采用SPI机制能够解耦和降低维护成本；

SPI机制使用约定：

从上面的图中，我们可以清晰的知道SPI的三部分：接口+实现类+配置文件；因此，项目中若要利用SPI机制，则需要遵循以下约定：

当服务提供者提供了接口的一种具体实现后，在jar包的META-INF/services目录下创建一个以“接口全限定名”为命名的文件，内容为实现类的全限定名。 主程序通过java.util.ServiceLoder动态装载实现模块，它通过扫描META-INF/services目录下的配置文件找到实现类的全限定名，把类加载到JVM；

注意：除SPI，我还发布了最新Java架构项目实战教程+大厂面试题库， 点击此处免费获取，小白勿进！

2.实践

整体包结构如图：

新建标准化接口：

public interface SayService { void say(String word);}

建立两个实现类

@Servicepublic class ASayServiceImpl implements SayService { @Override public void say(String word) { System.out.println(word + ' A say: I am a boy'); }}@Servicepublic class BSayServiceImpl implements SayService { @Override public void say(String word) { System.out.println(word + ' B say: I am a girl'); }}

新建META-INF/services目录和配置文件（以接口全限定名）

配置文件内容为实现类全限定名

com.qxy.spi.impl.ASayServiceImplcom.qxy.spi.impl.BSayServiceImpl

单测

@SpringBootTest@RunWith(SpringRunner.class)public class SpiTest { static ServiceLoader<SayService> services = ServiceLoader.load(SayService.class); @Test public void test1() { for (SayService sayService : services) { sayService.say('Hello'); } }}

结果

Hello A say: I am a boyHello B say: I am a girl

3.源码

源码主要加载流程如下：

应用程序调用ServiceLoader.load方法 ServiceLoader.load方法内先创建一个新的ServiceLoader，并实例化该类中的成员变量；

loader(ClassLoader类型，类加载器) acc(AccessControlContext类型，访问控制器) providers(LinkedHashMap<String,S>类型，用于缓存加载成功的类) lookupIterator(实现迭代器功能)

应用程序通过迭代器接口获取对象实例 ServiceLoader先判断成员变量providers对象中(LinkedHashMap<String,S>类型)是否有缓存实例对象，如果有缓存，直接返回。如果没有缓存，执行类的装载。

读取META-INF/services/下的配置文件，获得所有能被实例化的类的名称，值得注意的是，ServiceLoader可以跨越jar包获取META-INF下的配置文件； 通过反射方法Class.forName()加载类对象，并用instance()方法将类实例化。 把实例化后的类缓存到providers对象中，(LinkedHashMap<String,S>类型） 然后返回实例对象。

public final class ServiceLoader<S> implements Iterable<S>{ // 加载具体实现类信息的前缀 private static final String PREFIX = 'META-INF/services/'; // 需要加载的接口 // The class or interface representing the service being loaded private final Class<S> service; // 用于加载的类加载器 // The class loader used to locate, load, and instantiate providers private final ClassLoader loader; // 创建ServiceLoader时采用的访问控制上下文 // The access control context taken when the ServiceLoader is created private final AccessControlContext acc; // 用于缓存已经加载的接口实现类，其中key为实现类的完整类名 // Cached providers, in instantiation order private LinkedHashMap<String,S> providers = new LinkedHashMap<>(); // 用于延迟加载接口的实现类 // The current lazy-lookup iterator private LazyIterator lookupIterator; public void reload() { providers.clear(); lookupIterator = new LazyIterator(service, loader); } private ServiceLoader(Class<S> 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(); } private static void fail(Class<?> service, String msg, Throwable cause) throws ServiceConfigurationError { throw new ServiceConfigurationError(service.getName() + ': ' + msg, cause); } private static void fail(Class<?> service, String msg) throws ServiceConfigurationError { throw new ServiceConfigurationError(service.getName() + ': ' + msg); } private static void fail(Class<?> service, URL u, int line, String msg) throws ServiceConfigurationError { fail(service, u + ':' + line + ': ' + msg); } // Parse a single line from the given configuration file, adding the name // on the line to the names list. //具体解析资源文件中的每一行内容 private int parseLine(Class<?> service, URL u, BufferedReader r, int lc, List<String> names) throws IOException, ServiceConfigurationError { String ln = r.readLine(); if (ln == null) { //-1表示解析完成 return -1; } // 如果存在’#’字符，截取第一个’#’字符串之前的内容，’#’字符之后的属于注释内容 int ci = ln.indexOf(’#’); if (ci >= 0) ln = ln.substring(0, ci); ln = ln.trim(); int n = ln.length(); if (n != 0) { //不合法的标识：’ ’、’t’ if ((ln.indexOf(’ ’) >= 0) || (ln.indexOf(’t’) >= 0))fail(service, u, lc, 'Illegal configuration-file syntax'); int cp = ln.codePointAt(0); //判断第一个 char 是否一个合法的 Java 起始标识符 if (!Character.isJavaIdentifierStart(cp))fail(service, u, lc, 'Illegal provider-class name: ' + ln); //判断所有其他字符串是否属于合法的Java标识符 for (int i = Character.charCount(cp); i < n; i += Character.charCount(cp)) {cp = ln.codePointAt(i);if (!Character.isJavaIdentifierPart(cp) && (cp != ’.’)) fail(service, u, lc, 'Illegal provider-class name: ' + ln); } //不存在则缓存 if (!providers.containsKey(ln) && !names.contains(ln))names.add(ln); } return lc + 1; } private Iterator<String> parse(Class<?> service, URL u) throws ServiceConfigurationError { InputStream in = null; BufferedReader r = null; ArrayList<String> names = new ArrayList<>(); try { in = u.openStream(); r = new BufferedReader(new InputStreamReader(in, 'utf-8')); int lc = 1; while ((lc = parseLine(service, u, r, lc, names)) >= 0); } catch (IOException x) { fail(service, 'Error reading configuration file', x); } finally { try {if (r != null) r.close();if (in != null) in.close(); } catch (IOException y) {fail(service, 'Error closing configuration file', y); } } return names.iterator(); } // Private inner class implementing fully-lazy provider lookup // private class LazyIterator implements Iterator<S> { Class<S> service; ClassLoader loader; // 加载资源的URL集合 Enumeration<URL> configs = null; // 需加载的实现类的全限定类名的集合 Iterator<String> pending = null; // 下一个需要加载的实现类的全限定类名 String nextName = null; private LazyIterator(Class<S> service, ClassLoader loader) { this.service = service; this.loader = loader; } private boolean hasNextService() { if (nextName != null) {return true; } if (configs == null) {try {// 资源名称，META-INF/services + 全限定名 String fullName = PREFIX + service.getName(); if (loader == null) configs = ClassLoader.getSystemResources(fullName); else configs = loader.getResources(fullName);} catch (IOException x) { fail(service, 'Error locating configuration files', x);} } // 从资源中解析出需要加载的所有实现类的全限定名 while ((pending == null) || !pending.hasNext()) {if (!configs.hasMoreElements()) { return false;}pending = parse(service, configs.nextElement()); } //下一个需要加载的实现类全限定名 nextName = pending.next(); return true; } private S nextService() { if (!hasNextService())throw new NoSuchElementException(); String cn = nextName; nextName = null; Class<?> c = null; try { //反射构造Class实例c = Class.forName(cn, false, loader); } catch (ClassNotFoundException x) {fail(service, 'Provider ' + cn + ' not found'); } // 类型判断，校验实现类必须与当前加载的类/接口的关系是派生或相同，否则抛出异常终止 if (!service.isAssignableFrom(c)) {fail(service, 'Provider ' + cn + ' not a subtype'); } try { //强转S p = service.cast(c.newInstance()); // 实例完成，添加缓存，Key：实现类全限定类名，Value：实现类实例providers.put(cn, p);return p; } catch (Throwable x) {fail(service, 'Provider ' + cn + ' could not be instantiated', x); } throw new Error(); // This cannot happen } public boolean hasNext() { if (acc == null) {return hasNextService(); } else {PrivilegedAction<Boolean> action = new PrivilegedAction<Boolean>() { public Boolean run() { return hasNextService(); }};return AccessController.doPrivileged(action, acc); } } public S next() { if (acc == null) {return nextService(); } else {PrivilegedAction<S> action = new PrivilegedAction<S>() { public S run() { return nextService(); }};return AccessController.doPrivileged(action, acc); } } public void remove() { throw new UnsupportedOperationException(); } } public Iterator<S> iterator() { return new Iterator<S>() { Iterator<Map.Entry<String,S>> knownProviders= providers.entrySet().iterator(); public boolean hasNext() {if (knownProviders.hasNext()) return true;return lookupIterator.hasNext(); } public S next() {if (knownProviders.hasNext()) return knownProviders.next().getValue();return lookupIterator.next(); } public void remove() {throw new UnsupportedOperationException(); } }; } public static <S> ServiceLoader<S> load(Class<S> service, ClassLoader loader) { // 返回ServiceLoader的实例 return new ServiceLoader<>(service, loader); } public static <S> ServiceLoader<S> loadInstalled(Class<S> service) { ClassLoader cl = ClassLoader.getSystemClassLoader(); ClassLoader prev = null; while (cl != null) { prev = cl; cl = cl.getParent(); } return ServiceLoader.load(service, prev); } public String toString() { return 'java.util.ServiceLoader[' + service.getName() + ']'; }}

4.总结

SPI机制在实际开发中使用得场景也有很多。特别是统一标准的不同厂商实现，溪源也正是利用SPI机制(但略做改进，避免过多加载资源浪费)实现不同技术平台的结果文件解析需求。

优点

使用Java SPI机制的优势是实现解耦，使得第三方服务模块的装配控制的逻辑与调用者的业务代码分离，而不是耦合在一起。应用程序可以根据实际业务情况启用框架扩展或替换框架组件。

缺点

虽然ServiceLoader也算是使用的延迟加载，但是基本只能通过遍历全部获取，也就是接口的实现类全部加载并实例化一遍。如果你并不想用某些实现类，它也被加载并实例化了，这就造成了浪费。

源码传送门：SPI Service

到此这篇关于详解java实践SPI机制及浅析源码的文章就介绍到这了,更多相关java SPI机制内容请搜索好吧啦网以前的文章或继续浏览下面的相关文章希望大家以后多多支持好吧啦网！