Java内部具有原子更新的动态热交换环境

有人可能会说上述标题可以简称为OSGi ，我想在一开始就放弃这种思考过程。

对于OSGi而言，这不是一个冒犯，这是一个很棒的规范，在实现层或可用性层上都弄得一团糟，这就是我对OSGi的信念。当然，您可以使用OSGi进行此操作，但同时还要进行一些自定义工作。使用OSGi解决此问题的缺点是在开发过程中引入了不必要的复杂性。我们受到了JRebel的启发，并且想了一会儿，我们想要并很快意识到那条线上的东西，我们不想在生产级运行时进行字节码注入。因此让我们分析问题领域。

问题域

我们要解决的问题与UltraESB有关，具体来说就是实时更新功能。 UltraESB支持以原子方式向正在运行的ESB更新/添加新的配置片段（称为“ 部署单元 ”），而不会造成停机时间，最重要的是不会出现任何不一致的状态。但是，此功能的局限性之一是，如果特定的Java类驻留在用户类空间中，则需要对此部署单元的配置更新进行更改，因此需要重新启动JVM。尽管在集群部署中（使用循环重启）可以承受，但是在单实例部署中，这给整个系统带来了停机时间。

我们必须确保在解决这一问题时几乎没有任何保证；

在更新部署单元时，该单元已经接受的消息应使用所有资源，包括现有单元的已加载类（以及要加载的任何新类），而任何新消息（在完成单元更新后）都必须使用被调度到新的部署单元配置和资源库，我们称之为“ 一致性保证 ”。
为了确保这一点，我们需要在同一JVM上管理同一类的2个（或更多个）相同类的版本，以使各个部署单元以原子方式使用这些类。让我们称其为部署单元的“ 原子性保证 ”。
部署单元配置可能包含Java片段，这些Java片段在更新时进行即时编译，其中可能包含对更新后的类的依赖关系，从而使编译器能够找到该类的新版本以进行编译过程。这就是“ 正确性保证 ”
更新过程必须对用户透明（他们不必担心这一点，无论是在开发时间上还是在部署时间上），并且整个过程应该很简单。让我们称之为“ 简单性保证 ”

现在您将理解这个问题不仅仅是OSGi，因为编译是至少在我撰写此博客时OSGi无法自行解决的问题（AFAIK）。

如果我回到OSGi，以确保它非常清晰，为什么我们不走这条路呢？让我们详细分析需求。我们真正想要的不是完全模块化的JVM，而是JVM内部可动态且原子可重新加载的特定空间。将其映射到我们的实际用例中，可以确保用户写入并插入ESB的任何内容（即包含代理服务，序列和中介逻辑的部署单元）都可以动态地自动重新加载，可版本化，但不能像在ESB核心中执行用户代码。这是用户向我们询问的内容，而不是您如何在不重新启动的情况下如何在运行时向ESB添加其他功能。我同意能够添加新功能很酷，但是似乎没有人希望这样做以及与之相关的复杂性。我们已经准备好进行任何复杂的工作，但是还没有准备好将这种复杂性或任何复杂性传递给我们的用户。

拟议的解决方案

如果您想在Java中使用前2个保证“ Consistency / Atomicity ”（能够在运行时加载同一个类的2个版本，并在其中的正确任务中使用正确的类），则除了编写之外，别无他法一个新的类加载器，它强制JVM执行子优先级加载 。 JVM标准类装入器都是“父优先”的。典型应用程序容器的WebAppClassLoader与我们想要的非常接近，但是在生产环境中具有动态重载功能。旧类空间和新类空间应由该类加载器的2个实例管理，以便能够安全地隔离这2个版本。

要了解上述事实，重要的是要了解JVM如何识别类。即使从Java语言的角度来看，类也是由FQN唯一标识的，即FQN，即“包名+类名”，但是从JVM的角度来看，除了上述概念外，已经加载了该类的类加载器也是一个事实班级的独特性。在类似OSGi的环境中，这就是为什么即使您强制转换为正确的类型也看到ClassCastException的原因。因此得出的结论是，我们需要编写一个类加载器，并为可重新加载的不同部署单元的不同版本保留该类加载器的单独实例。

为了确保即时编译器看到正确的类来编译序列片段，从而保证“ 正确性 ”，需要有一个JavaFileManager实现，再次寻找更新的类空间。 Java编译器任务javac通过指定的文件管理器（作为JavaFileObject实例）而不是通过类加载器（作为类对象）来搜索依赖项以编译类，这是为了确保编译器有效地解析类，因为可能存在依赖项在正在编译的类中。

此外，不应该要求用户将jar文件放在经过版本控制的文件结构中，以免影响对“ 简单性 ”的保证，而ESB本身必须管理该jar文件的版本控制以确保我们不会混合使用不同的版本类空间。这对于在不同版本中正确执行编译器任务也很重要，因为编译器使用“ 内存映射”文件读取文件管理器提供的类的输入流上的类定义，从而强制维护每个文件的物理副本。 jar文件/类的版本。

执行执行

首先让我指出完整的变更集，在阅读实现时可以不时参考。

我们已经确定了3个要实现的关键空间，其中第一个是提供用户类空间的类的类加载器。我们将其命名为HotSwapClassLoader （我不会在博客中向您显示代码片段，请记住该完整代码，请牢记AGPL许可的条款，因为该代码为AGPL ）。现在，我们想将此类加载器与部署单元的版本相关联，UltraESB固有地支持该版本加载器，因为它将它们保持为单独的Spring子上下文。

因此，任何新的部署单元配置创建（包括现有部署单元的新版本）都将实例化此类加载器的新实例，并将其用作部署单元配置的资源/类加载器。初始化时的类加载器计算用户类空间的规范化哈希值，并检查当前版本的类空间是否存在现有副本，并根据上述声明使用该副本或创建新副本。这种散列和重用类空间的现有副本会阻止管理同一用户类空间版本的2个副本，因为整个过程都是在静态最终锁上同步的。然后，它对用户类空间的该副本进行操作。必须进行此复制，以免让用户担心类的版本控制，并确保在给定的配置中使用了正确的类集。该类装入器还采取了广泛的措施，以确保尽早清除类空间副本。但是，这只能保证最终清除。

执行的下一个主要项目是InMemoryFileManager哪个是哪个得到改性通过列表的方法的一个可迭代以支持另外的用户类的空间来在内存中的编译源代码片段现有类SwappableJavaFileObject实例。文件管理器首先查询HotSwapClassLoader，以查找与用户类空间相对应的SwappableJavaFileObject实例，然后是系统类空间，并以WrappedIterator的形式返回，以确保用户空间类获得优先级。

在实现的最后一步中，对核心JVM功能进行了调整/自定义之后，只需使用此自定义类加载器来加载序列和代理服务的类，并为片段编译任务提供自定义文件管理器即可。部署单元以完成解决方案。我们还希望有一个开关在默认情况下将其禁用，并建议在生产部署中将其禁用。为了简化运行时环境并进行其他一些自定义，UltraESB引入了环境概念，该概念是从Grails环境功能中借用的。

最后，成功实现了动态运行时，即“一致”，“原子”，“正确”，最重要的是“对用户简单”。

操作行为

现在，我们已经实现了解决方案，让我们看一下UltraESB的内部结构，了解它在生产部署中如何工作。发出配置添加或更新管理命令后，将更新生产环境中的所有部署单元配置。可以通过原始JMX或通过在JMX操作之上实现的任何管理工具（例如UTerm ）或通过UConsole发出此命令。

完成此实现后，它不会对您进行更新的方式进行任何更改，它通过添加/替换jar文件的功能进一步增强了功能，并进行了修改，从而将更新影响到UltraESB的lib / custom用户类空间中，从而确保了在更新后发出每个所述管理命令后，为新配置选择更新的jar文件/类。
您可以在UltraESB的夜间版本中尝试此操作，甚至可以等待2.0.0版本的发布，该版本计划在2013年1月中旬发布更多新的酷但可用的功能。

参考： Java内部的动态热交换环境，我们的JCG合作伙伴 Ruwan Linton在
Blind Vision –来自软件工程与生活博客。

翻译自: https://www.javacodegeeks.com/2012/12/dynamic-hot-swap-environment-inside-java-with-atomic-updates.html