具有多个类加载器的 Java ServiceLoader

Question

使用 ServiceLoader 的最佳实践是什么？在具有多个类加载器的环境中？该文档建议在初始化时创建并保存单个服务实例:

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

这将使用当前上下文类加载器初始化 ServiceLoader。现在假设这个片段包含在一个使用 Web 容器中的共享类加载器加载的类中，并且多个 Web 应用程序想要定义自己的服务实现。这些不会在上面的代码中得到，甚至有可能使用第一个 webapps 上下文类加载器初始化加载器并向其他用户提供错误的实现。

总是创建一个新的 ServiceLoader 似乎很浪费性能，因为它每次都必须枚举和解析服务文件。 编辑:这甚至可能是一个很大的性能问题，如 this answer regarding java's XPath implementation 所示。 .

其他图书馆如何处理这个问题？他们是否缓存每个类加载器的实现，他们是否每次都重新解析他们的配置，或者他们只是忽略这个问题并且只对一个类加载器有效？

Answer 1

我个人不喜欢ServiceLoader在任何情况下。它很慢而且没有必要的浪费，而且你几乎无能为力来优化它。

我还发现它有点受限制——如果你想做的不仅仅是按类型搜索，你真的必须走自己的路。

xbean-finder 的 ResourceFinder

ResourceFinder是一个独立的 java 文件，能够替代 ServiceLoader 的使用。复制/粘贴重用没问题。它是一个 Java 文件，获得了 ASL 2.0 许可，可从 Apache 获得。

在我们的注意力变得太短之前，这里是它如何取代 ServiceLoader

ResourceFinder finder = new ResourceFinder("META-INF/services/");
List<Class<? extends Plugin>> impls = finder.findAllImplementations(Plugin.class);

这将找到所有 META-INF/services/org.acme.Plugin类路径中的实现。

请注意，它实际上并未实例化所有实例。选择你想要的，你就是一个 newInstance()调用远离实例。

为什么这很好？

打电话有多难newInstance()有适当的异常处理？不难。

拥有仅实例化您想要的实例的自由是很好的。

现在你可以支持构造函数参数了!

缩小搜索范围

如果您只想检查特定的 URL，您可以轻松完成:

URL url = new File("some.jar").toURI().toURL();
ResourceFinder finder = new ResourceFinder("META-INF/services/", url);

在这里，将只搜索“some.jar”这个 ResourceFinder 实例的任何用法。

还有一个名为 UrlSet 的便利类这可以使从类路径中选择 URL 变得非常容易。

ClassLoader webAppClassLoader = Thread.currentThread().getContextClassLoader(); 
UrlSet urlSet = new UrlSet(webAppClassLoader);
urlSet = urlSet.exclude(webAppClassLoader.getParent());
urlSet = urlSet.matching(".*acme-.*.jar");

List<URL> urls = urlSet.getUrls();

替代“服务”风格

假设您想申请 ServiceLoader类型概念来重新设计 URL 处理和查找/加载 java.net.URLStreamHandler对于特定的协议(protocol)。

以下是在类路径中布局服务的方法:

META-INF/java.net.URLStreamHandler/foo

META-INF/java.net.URLStreamHandler/bar

META-INF/java.net.URLStreamHandler/baz

哪里foo是一个纯文本文件，其中包含与以前一样的服务实现的名称。现在说有人创建了一个 foo://...网址。我们可以通过以下方式快速找到实现:

ResourceFinder finder = new ResourceFinder("META-INF/");
Map<String, Class<? extends URLStreamHandler>> handlers = finder.mapAllImplementations(URLStreamHandler.class);
Class<? extends URLStreamHandler> fooHandler = handlers.get("foo");

替代“服务”样式 2

假设您想在您的服务文件中放入一些配置信息，因此它包含的不仅仅是一个类名。这是将服务解析为属性文件的替代样式。按照惯例，一个键是类名，其他键是可注入(inject)的属性。

所以这里red是一个属性文件

META-INF/org.acme.Plugin/red

META-INF/org.acme.Plugin/blue

META-INF/org.acme.Plugin/green

您可以像以前一样查找内容。

ResourceFinder finder = new ResourceFinder("META-INF/");

Map<String,Properties> plugins = finder.mapAllProperties(Plugin.class.getName());
Properties redDefinition = plugins.get("red");

以下是如何将这些属性与 xbean-reflect 一起使用，另一个可以为您提供无框架 IoC 的小库。你只需给它类名和一些名称值对，它就会构造和注入(inject)。

ObjectRecipe recipe = new ObjectRecipe(redDefinition.remove("className").toString());
recipe.setAllProperties(redDefinition);

Plugin red = (Plugin) recipe.create();
red.start();

以下是长格式的“拼写”方式:

ObjectRecipe recipe = new ObjectRecipe("com.example.plugins.RedPlugin");
recipe.setProperty("myDateField","2011-08-29");
recipe.setProperty("myIntField","100");
recipe.setProperty("myBooleanField","true");
recipe.setProperty("myUrlField","http://www.stackoverflow.com");
Plugin red = (Plugin) recipe.create();
red.start();

xbean-reflect library 是内置 JavaBeans API 之外的一步，但在不需要您一直使用完整的 IoC 框架(如 Guice 或 Spring)的情况下要好一些。它支持工厂方法和构造函数参数以及 setter /字段注入(inject)。

为什么ServiceLoader 如此有限？

JVM 中弃用的代码会损坏 Java 语言本身。许多东西在被添加到 JVM 之前被修剪到骨骼，因为你不能在之后修剪它们。 ServiceLoader就是一个典型的例子。 API 是有限的，OpenJDK 实现大约有 500 行，包括 javadoc。

那里没有什么花哨的东西，更换它很容易。如果它对您不起作用，请不要使用它。

类路径范围

撇开 API 不谈，在纯粹的实践中，缩小搜索 URL 的范围是解决这个问题的真正方法。应用服务器本身有很多 URL，不包括应用程序中的 jar。例如，OSX 上的 Tomcat 7 仅在 StandardClassLoader 中就有大约 40 个 URL(这是所有 webapp 类加载器的父类)。

您的应用服务器越大，即使是简单的搜索也需要更长的时间。

如果您打算搜索多个条目，则缓存无济于事。同样，它会增加一些不好的泄漏。可能是一个真正的双输局面。

将 URL 缩小到您真正关心的 5 或 12 个，您可以执行各种服务加载而不会注意到命中。