前言

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

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

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

“Service Provider“标准

”Service Provider”首先是作为一个标准被Javase所吸纳&＃xff1a;

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

标准中对”Service Provider”的定义可以总结为三句话&＃xff1a;

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

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

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

服务加载机制

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

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

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

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

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

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

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

服务使用者

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

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

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

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

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

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

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 { //打招呼函数&＃xff0c;供Python脚本调用 public static void sayHello(String name) { System.out.format("Hello %s!", name); }public static void callPython() { //Jython引擎使用前需要提前做一些初始化工作 Properties props &＃61; new Properties(); props.setProperty("python.import.site", "false"); PythonInterpreter.initialize(System.getProperties(), props, new String[]{}); //创建脚本引擎管理器 ScriptEngineManager m &＃61; new ScriptEngineManager(); //通过脚本引擎管理器查找并创建jython引擎 ScriptEngine pyEngine &＃61; m.getEngineByName("jython"); try { //执行Python脚本&＃xff0c;在其中调用java函数 pyEngine.eval("from org.ctstudio import PyScriptEngineDemo" &＃43; "PyScriptEngineDemo.sayHello(&＃39;Jack&＃39;)"); //Hello Jack! } catch (ScriptException e) { e.printStackTrace(); } } public static void main(String[] args) { callPython(); }}

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

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

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

org.apache.catalina.startup.ContextConfig:

org.apache.catalina.core.StandardContext:

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

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

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

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

结语

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