spring解密_在运行时更新代码（已Spring解密）

傷城~ 2023-02-25 03:45 7阅读 0赞

spring解密

当从编译到部署再到测试的开发周期花费太长时间时，人们希望能够及时替换正在运行的代码，而无需重新启动应用程序服务器并等待部署完成。 在这种情况下，像[JRebel][]这样的商业解决方案或像[Grails][]这样的开源框架就可以提供帮助。

JVM不支持开箱即用地替换代码，例如您可以使用`Class.forName()`动态加载类。 基本上，您有以下选择：

*  HotSwap：Java 1.4引入的技术，可让您在调试器会话中重新定义类。 这种方法非常有限，因为它仅允许您更改方法的主体，而不能添加新的方法或类。
 *  OSGi：此技术使您可以定义包。 在运行时，可用此软件包的较新版本替换该软件包。
 *  一次性的类加载器：通过在模块的所有类上包装单独的类加载器，可以在模块的新版本可用时丢弃该类加载器并进行替换。
 *  使用Java代理检测类：Java代理可以在定义类之前进行检测。 这样，它可以将代码注入到已加载的类中，该类将此类与类文件的一个版本连接起来。 一旦有新版本可用，将执行新代码。

Grails的技术称为“ [弹簧加载”，][Link 1]并使用“ Java代理”方法来处理从文件系统而不是从jar文件加载的类。 但是，这在后台如何工作？

为了了解弹簧负载，我们建立了一个小样本项目，使我们可以更详细地研究该技术。 该项目仅包含两个类： `Main`类调用`ToBeChanged`类的`print()`方法，并Hibernate一会儿：

public static void main(String[] args) throws InterruptedException {
      while (true) {
        ToBeChanged toBeChanged = new ToBeChanged();
        toBeChanged.print();
        Thread.sleep(500);
      }
    }

`print()`方法仅打印出一个版本，以便我们可以看到它已更改。 另外，我们还打印出堆栈跟踪，以查看其随时间的变化：

public void print() {
      System.out.println("V1");
      StackTraceElement[] stackTrace = Thread.currentThread().getStackTrace();
      for (StackTraceElement element : stackTrace) {
        System.out.println("\t" + element.getClassName() + "." 
          + element.getMethodName() + ":" + element.getLineNumber());
      }
    }

启动应用程序时，我们必须使用选项`javaagent`提供包含Java Agent的jar文件。 当弹簧加载以验证者不喜欢的方式修改字节码时，我们必须通过将选项`noverify`传递给JVM来禁用字节码的验证。 最后，我们用`cp`传递包含类文件的文件夹，并告诉JVM包含`main()`方法的类：

java -javaagent:springloaded-1.2.4.BUILD-SNAPSHOT.jar 
      -noverify 
      -cp target/classes 
      com.martinsdeveloperworld.springloaded.Main

将`ToBeChanged`类的版本从`V1`更新到`V2`并使用`mvn package`重建项目后，我们将看到以下输出：

...
    V1
            java.lang.Thread.getStackTrace:-1
            com.martinsdeveloperworld.springloaded.ToBeChanged.print:7
            com.martinsdeveloperworld.springloaded.Main.main:8
    V2
            java.lang.Thread.getStackTrace:-1
            com.martinsdeveloperworld.springloaded.ToBeChanged$$EPBF0gVl.print:7
            com.martinsdeveloperworld.springloaded.ToBeChanged$$DPBF0gVl.print:-1
            com.martinsdeveloperworld.springloaded.ToBeChanged.print:-1
            com.martinsdeveloperworld.springloaded.Main.main:8
    ...

版本`V1`的stacktrace看起来像我们期望的那样。 从`Main.main()`方法`ToBeChanged.print()`被调用。 对于版本`V2`这是不同的。 在这里，方法`ToBeChanged.print`现在调用方法`ToBeChanged$$DPBF0gVl.print()` 。 还请注意，调用`ToBeChanged.print()`的行号已从8更改为-1，表示该行未知。

新的行号-1强烈表明Java代理已经以一种允许它调用新方法而不是执行旧代码的方式来检测`ToBeChanged.print()`方法。 为了证明这一假设，我在spring-loaded的代码中添加了一些日志记录语句，并添加了一个功能，可将每个插入的文件转储到本地硬盘驱动器中。 通过这种方式，我们可以检查`ToBeChanged.print()`后方法`ToBeChanged.print()`外观：

0 getstatic #16 <com/martinsdeveloperworld/springloaded/ToBeChanged.r$type>
      3 ldc #72 <0>
      5 invokevirtual #85 <org/springsource/loaded/ReloadableType.changed>
      8 dup
      9 ifeq 42 (+33)
     12 iconst_1
     13 if_icmpeq 26 (+13)
     16 new #87 <java/lang/NoSuchMethodError>
     19 dup
     20 ldc #89 <com.martinsdeveloperworld.springloaded.ToBeChanged.print()V>
     22 invokespecial #92 <java/lang/NoSuchMethodError.<init>>
     25 athrow
     26 getstatic #16 <com/martinsdeveloperworld/springloaded/ToBeChanged.r$type>
     29 invokevirtual #56 <org/springsource/loaded/ReloadableType.fetchLatest>
     32 checkcast #58 <com/martinsdeveloperworld/springloaded/ToBeChanged__I>
     35 aload_0
     36 invokeinterface #94 <com/martinsdeveloperworld/springloaded/ToBeChanged__I.print> count 2
     41 return
     42 pop
     43 getstatic #100 <java/lang/System.out>
     46 ldc #102 <V1>
     48 invokevirtual #107 <java/io/PrintStream.println>
     51 invokestatic #113 <java/lang/Thread.currentThread>
     54 invokevirtual #117 <java/lang/Thread.getStackTrace>
     57 astore_1
    ...
    152 return

`getstatic`操作码检索新字段`r$type`的值并将其压入堆栈（操作码`ldc` ）。 然后，调用方法`ReloadableType.changed()`来调用之前已推入堆栈的对象引用。 顾名思义，方法`ReloadableType.changed()`检查此类型的新版本是否存在。 如果方法未更改，则返回0；如果方法已更改，则返回1。 如果返回值为零，即方法未更改，则以下操作码`ifeq`跳至第42行。 从第42行开始，我们看到了原始实现，在这里我将其缩短了一点。

如果值为1，则`if_icmpeq`指令跳至第26行，在此再次读取静态字段`r$type` 。 此引用用于在其上调用方法`ReloadableType.fetchLatest()` 。 下面的`checkcast`指令验证返回的引用的类型为`ToBeChanged__I` 。 在这里，我们第一次偶然发现了这种弹簧接口为每种类型生成的人工接口。 它反映了原始类在检测时所具有的方法。 两行之后，此接口用于在`ReloadableType.fetchLatest()`返回的引用上调用方法`print()` `ReloadableType.fetchLatest()` 。

该引用不是对该类的新版本的引用，而是对所谓的调度程序的引用。 调度程序实现`ToBeChanged__I`接口，并通过以下指令实现方法`print()` ：

0 aload_1
    1 invokestatic #21 <com/martinsdeveloperworld/springloaded/ToBeChanged$$EPBF0gVl.print>
    4 return

动态生成的类`ToBeChanged$$EPBF0gVl`是所谓的执行程序，体现了该类型的新版本。 对于每个新版本，都会创建一个新的调度程序和执行程序，只有接口保持不变。 一旦有新版本可用，则在新调度程序上调用接口方法，并且在最简单的情况下，该接口方法将转发至执行程序中包含的代码的新版本。 不能直接在执行器上调用接口方法的原因是，弹簧加载还可以处理在新版本的类中添加方法的情况。 由于此方法在旧版本中不存在，因此将通用方法`__execute()`添加到接口和调度程序。 然后，此动态方法可以将调用调度到新方法，如从生成的调度程序中获取的以下指令集中所示：

0 aload_3
     1 ldc #25 <newMethod()V>
     3 invokevirtual #31 <java/lang/String.equals>
     6 ifeq 18 (+12)
     9 aload_2
    10 checkcast #33 <com/martinsdeveloperworld/springloaded/ToBeChanged>
    13 invokestatic #36 <com/martinsdeveloperworld/springloaded/ToBeChanged$$EPBFaboY.newMethod>
    16 aconst_null
    17 areturn
    18 aload_3
    ...
    68 areturn

在这种情况下，我向类`ToBeChanged`添加了一个名为`newMethod()`的新方法。 `__execute()`方法的开头比较调用的描述符是否与新方法匹配。 在这种情况下，它将调用转发给新的执行者。 为了使此工作正常进行，必须将新方法的所有调用都重写为`__execute()`方法。 这也可以通过对原始类的检测来完成，并且也可以进行反射。

## 结论 ##

Spring加载演示了可以在运行时用较新版本“替换”一个类。 为了实现这一点，利用了一系列Java技术，例如Java Agent和字节码检测。 通过仔细研究实现，可以大致了解有关JVM和Java的许多知识。

> 翻译自: [https://www.javacodegeeks.com/2015/05/updating-code-at-runtime-spring-loaded-demystified.html][https_www.javacodegeeks.com_2015_05_updating-code-at-runtime-spring-loaded-demystified.html]

spring解密

[JRebel]: http://zeroturnaround.com/software/jrebel/
[Grails]: https://grails.org/wiki/Auto%20Reloading
[Link 1]: https://github.com/spring-projects/spring-loaded
[https_www.javacodegeeks.com_2015_05_updating-code-at-runtime-spring-loaded-demystified.html]: https://www.javacodegeeks.com/2015/05/updating-code-at-runtime-spring-loaded-demystified.html