架构师必知必会：Java内置的控制反转机制-Service Provider

欢迎大家来到IT世界,在知识的湖畔探索吧!

前言

Java统治服务器编程领域多年还未有退位趋势，以IoC(控制反转)思想为核心的Spring功不可没。大多数时候，我们都可以使用Spring框架来实现我们的依赖注入，但仍有很多场景，我们期望自己的代码有更少的依赖、适应更多的场景，比如跨Android和服务端、跨JVM语言的组件拼装。

其实从Java6开始已经提供了一套依赖注入标准“Service Provider”和相应的工具”ServiceLoader”来实现我们自己的控制反转，且其已经广泛应用在JDK的扩展性设计之中(如：脚本引擎ScriptEngine, 字符集Charset, 文件系统FileSystems, 网络通讯NIO)，并越来越多地被其它开源组件所使用(如：Web标准Servlet3.0, 通用日志接口slf4j-api:1.3)，Java9进一步对“Service Provider”进行扩展实现了Java的模块化。所以”Service Provider”机制是Java越来越重要的基础知识之一。

容我带领各位，通过JDK文档和源码来一步步了解”Service Provider”，进而掌握通过Java自带能力零依赖实现自己的动态依赖注入的方法，或按Java标准来扩展JDK、日志、Http服务的能力。

“Service Provider“标准

”Service Provider”首先是作为一个标准被Javase所吸纳：

https://docs.oracle.com/javase/6/docs/technotes/guides/jar/jar.html#Service_Provider

标准中对”Service Provider”的定义可以总结为三句话：

1. 一个”Service”(服务)就是一组知名的接口或(通常是抽象)类的集合，“Service Provider“(服务提供者)就是对服务的特定实现；
2. 服务提供者，通过jar包中的“META-INF/services/fully-qualified.name.of.service.Interface“文件包含实现类的完全限定名，将实现类发布为提供者；
3. 服务查找机制，通过遍历ClassPath中所有的上述文件内容，来查找并创建提供者的实例。

以上是”Service Provider”标准中最重要的三点，请大家务必完全理解并牢记于心，标准中还有其它一些限制条件，只需了解以便问题的快速定位，如：

1. 提供者必须包含无参构造函数，以便服务查找机制可以通过反射创建其实例；
2. 提供者发布文件中，可以通过”#”开头定义注释行；
3. 提供者发布文件中，可以通过换行来分隔多个实现类；
4. 须在安全上下文中调用服务查找者…

服务加载机制

JDK中内置了“Service Provider“加载工具类”ServiceLoader”，通过静态方法”ServiceLoader.load()”方法，即可创建指定类型的”Service Provider”迭代器（ServiceLoader本身），通过遍历迭代器即可得到所有Provider的实例。”ServiceLoader”的源代码可以在JDK中找到，实现”服务加载”最关键的是下面几段(以Oracle JDK8源码为例)：

1、”Service Provider”标准定义的服务发布文件路径前缀：

2、使用(系统或用户)ClassLoader找到指定”Service”的”Provider”所有发布文件

3、根据发布文件中的类名加载Provider的Class

4、通过Provider的Class创建Provider实例

我们看到ServiceLoader通过调用提供者Class的newInstance方法，创建了服务提供者的实例，这也是为什么服务提供者需要有一个无参构造函数的原因。

出于Web应用安全隔离的需要，Tomcat在实现Servlet3.0标准的” ServletContainerInitializer”应用自启动机制中，使用了遵循”Service Provider”标准的另一套服务查找实现”WebappServiceLoader”，主要区别在于去”WEB-INF/lib”下而不是直接通过类加载器查找”Service Provider”文件，感兴趣的同学可以去看Tomcat的源码：org.apache.catalina.startup.WebappServiceLoader

服务使用者

罗马不是一天建成的，JDK也是。从MessageDigest、Charset、ScriptEngine等诞生于Java不同时期的API来看，”Service Provider”标准和”ServiceLoader”工具类的使用从无到有，从选择之一到唯一选择，我们可以看出”Service Provider”和”ServiceLoader”机制将是扩展JDK已有服务(Charset、ScriptEngine、NIO等)的标准。

让我们一起通过脚本引擎ScriptEngine这一与”Service Provider”一起诞生的API，来学习如何通过”Service Provider”扩展JDK服务，以及玩转可扩展服务的设计。

从Java6开始，JDK内置了一套javascript脚本引擎”NashornScriptEngine”，可以很方便地在java里面直接解析、运行js脚本，为代码提供动态执行能力，而不用依赖任何第三方库：

 public static void callJavascript() { //创建脚本引擎管理器 ScriptEngineManager m = new ScriptEngineManager(); //通过脚本引擎管理器查找并创建javascript引擎 ScriptEngine jsEngine = m.getEngineByName("javascript"); try { //绑定预定义参数 Bindings bindings = jsEngine.getBindings(ScriptContext.ENGINE_SCOPE); bindings.put("a", 2); bindings.put("b", 3); //调用javascript的pow函数 Object result = jsEngine.eval("Math.pow(a,b)", bindings); //打印返回值”8.0” System.out.println(result); } catch (ScriptException e) { e.printStackTrace(); } } 

欢迎大家来到IT世界,在知识的湖畔探索吧!

变量、函数、与java互调用等更复杂的功能，大家可以一试，就不在本文的讨论范围之内。

除了自带的JavaScript引擎，通过”Service Provider”机制，很容易扩展ScriptEngine，支持其它脚本，比如引入”org.python:jython:2.7.0”后，ScriptEngine就具备了执行Python脚本的能力：

欢迎大家来到IT世界,在知识的湖畔探索吧!package org.ctstudio; import org.python.util.PythonInterpreter; import javax.script.ScriptEngine; import javax.script.ScriptEngineManager; import javax.script.ScriptException; import java.util.Properties; public class PyScriptEngineDemo { //打招呼函数，供Python脚本调用 public static void sayHello(String name) { System.out.format("Hello %s!\n", name); } public static void callPython() { //Jython引擎使用前需要提前做一些初始化工作 Properties props = new Properties(); props.setProperty("python.import.site", "false"); PythonInterpreter.initialize(System.getProperties(), props, new String[]{}); //创建脚本引擎管理器 ScriptEngineManager m = new ScriptEngineManager(); //通过脚本引擎管理器查找并创建jython引擎 ScriptEngine pyEngine = m.getEngineByName("jython"); try { //执行Python脚本，在其中调用java函数 pyEngine.eval("from org.ctstudio import PyScriptEngineDemo\n" + "PyScriptEngineDemo.sayHello('Jack')"); //Hello Jack! } catch (ScriptException e) { e.printStackTrace(); } } public static void main(String[] args) { callPython(); } } 

ScriptEngineManager是如何使用”Service Provider”机制的呢？通过JDK源代码，我们可以看到，ScriptEngineManager正是通过”ServiceLoader.load()”方法来发现所有脚本引擎：

由于脚本引擎实例的创建是一件开销比较大的事情，而”ServiceLoader”在迭代过程中就会直接创建提供者的实例，所以ScriptEngineManager没有直接返回ScriptEngine，而是使用抽象工厂模式发现并保存ScriptEngineFactory实例，只在真正需要的时候才通过具体工厂创建ScriptEngine的实例：

Servlet3.0的设计则较直接，”ServletContainerInitializer”的提供者被发现并创建实例，随后所有提供者的” onStartup”被调用，以触发用户自定义的初始化过程，具体可参考Tomcat的源码：

org.apache.catalina.startup.ContextConfig:

org.apache.catalina.core.StandardContext:

Java最有名的日志框架之一logback就是利用Servlet3.0的这一机制来初始化：

而Spring框架则利用Servlet3.0的这一机制实现了将Bean与服务提供者集成起来的WebApplicationInitializer，Spring-Boot则进一步在WebApplicationInitializer的基础之上实现了Web应用拉起工具基类SpringBootServletInitializer，使得我们可以在Servlet容器中轻松拉起我们的Spring应用：

最新版本的日志外观slf4j2.0(未发布)的LoggerFactory已改由”Service Provider”标准来加载日志实现：

Logback1.3(未发布，其作者也是log4j、slf4j的作者)也改用”Service Provider”机制来实现与日志外观的集成：

结语

如此多举足轻重的开源软件的重视，足以体现”Service Provider”作为Java标准的控制反转机制的重要影响，并可预见其将会越来越重要。不管你是想要为开源软件作贡献，或是设计自己的可扩展组件，”Service Provider”都是你有必要掌握的知识。