使用GraalVM本机映像的利弊

大家好，欢迎来到IT知识分享网。

本机映像是将Java应用程序转换为完全编译的二进制代码(称为本机映像)的实用程序。创建本机映像的过程称为提前编译。下面就开始讨论Native -image的优点和缺点。

什么时候更喜欢本地映像而不是普通的Java应用程序?

更快的启动

这对于两种类型的应用程序可能非常有趣:命令行应用程序和没有服务器的函数。这两种类型实际上有很多共同之处。它们通常较小，可以在很短的时间内多次启动，当然了，它们的周期也很短。

这就是为什么我们需要快速启动，而不是等待提供所有可能，却不会实际使用的JVM特性的原因(例如，我们需要让代码处于激活状态以触发JIT编译器)。

是什么让启动速度更快?

• 没有类加载

所有类都已经加载、链接，甚至部分初始化。但是，这意味着只有在映像构建过程中跟踪的类和方法包含在二进制文件中，并且可以在运行时使用。

• 没有解释的代码

生成的本机代码不必是完全有效的，因为我们不使用C2编译器中的配置文件引导优化(GraalVM Enterprise包含一个从以前的运行中收集的配置文件可以包含到本机映像的生成中)。但是，我们仍然不需要初始化解释器并解释我们的字节码。

• 不需要消耗CPU来进行分析和jit，启动GC非常简单(SerialGC)

通常并不需要启动JIT编译器和JIT代码来实现性能。

• 在本机映像构建期间生成映像堆

我们已经提到本机应用程序是部分启动的。这意味着我们可以运行初始化过程对于某些特定的类，在构建时(运行类静态块)准备堆的一部分并加速启动。

低内存占用

如果我们将代码编译成本机映像，那么我们可以从可执行文件中丢弃很多东西。这些JVM特性将不再被使用，因为它们不必使我们的代码更有效。但本机映像进程的RSS内存减少了，不过只减少了与jvm相关的内容和类元数据，堆内存保持不变。

由于当前在本地映像中使用的GC的性质，使用更大的堆会变得很笨拙，GC暂停会影响我们的延迟。但是，如果我们保持应用程序较小呢，就可以从本机映像GC的效率中获得好处(目前作为分代清除器实现)。

什么使内存占用更低:

• 加载的类没有元数据

工作中仍需要在非堆内存中编译代码。将动态加载的类的所有元数据保存在Metaspace中会节省很多空间(不需要在Metaspace中执行内存回收过程)

• 没有用于JIT优化的分析数据，没有解释器代码，没有JIT结构

JVM收集关于应用程序的分析数据，以确定可以应用哪种优化。这是不必要的，因为我们的字节码已经在本地代码中了。因此，我们可以丢弃包含分析数据和解释器的整个段代码缓存。优化后的方法以不同的方式存储在二进制文件中。

形象鲜明，前景光明

本节的最后一个注意事项是一个新特性——隔离。简单地说，Isolates是一种能够将堆划分成更小的独立“堆”的技术。应该是很有效的，例如在处理请求的情况下。

如果处理在堆上分配了大量对象，我们可以将请求(实际上是请求运行所在的线程)放入分离的隔离中。最大的优点是可以非常快速地分配和丢弃隔离，而不需要执行任何GC(都知道的，当线程离开给定的隔离时，所有对象都变成了垃圾，因为这些对象不必从其他隔离对象引用)。不过这个技术仍然在开发中，可以期待一下。

原生图像要付出什么代价？

本机映像是一种非常好的工具，适用于较小的应用程序，可以帮助我们启动和内存占用。然而，我们需要为此付出代价，并调整我们的应用程序，使之符合预先编译。我们可以在SubstrateVM限制中找到一组受支持和不受支持的特性。我只是简单地指出最痛苦的部分:

• 不支持JVMTI、Java代理、JMX、JFR

这可能是运行在JVM和本机映像上的应用程序之间的最大差距。本机映像不支持任何已知的通过JVMTI或JMX连接的分析器，我们需要依靠内核特性来确定我们的应用程序中发生了什么。通常用于检测类的Java代理也不受支持(通常用于测量执行时间或分配率)。在这种情况下，即使是Java飞行记录器和Java任务控制系统也是无价的。

• 仅对较小的堆有效

由于使用了SerialGC，我们不应该使用更大的堆，这可能会严重影响延迟。

• 生成的本机代码效率就那样吧

JIT因为它可以访问应用程序运行时配置文件，并且可以推测和插入陷阱来进行反优化，所以总是更有效。我们可以通过使用一个可用的基于概要文件的优化特性来减少AOT和JIT之间的差异GraalVM企业版。

• 反射模糊

我一点也不喜欢反射，但是很多框架都是基于反射的，它们必须进行调整或者使用额外的配置文件来定义二进制文件中的类和方法。我可以推荐一个关于SubstrateVM反射的非常详细的页面。

• 不支持线程转储和堆转储

喜欢就关注一下吧