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

java原子更新类