标签：java graalvm 构建 编译器 Kubernetes JRE

使用 Java、Javalin 和 GraalVM 构建 22 MB 的微服务

Oracle的GraalVM允许提前（AOT）编译JVM应用程序。这意味着，编译器不会运行 JVM 进程来执行应用程序，而是构建本机二进制文件。它是如何工作的？在非常高的层次上，基本运行时（称为SubstrateVM）被编译到二进制文件以及实际应用程序中。听起来有点像Go，它还包括一个小的运行时，例如垃圾收集。
在本文中，我将展示如何使用 GraalVM 本机编译构建一个小示例 restful Web 服务。示例应用程序是用 Java 编写的。
为什么有人甚至会对JVM应用程序的本机编译感兴趣？遗憾的是，在E.ON的日常工作中，我仍然需要大量使用Java应用程序。我们的技术堆栈完全是云原生的 - 我们几乎在 Kubernetes 上运行所有内容。我们的应用程序是“典型的”12 因素应用程序。在这样的 dockerized 环境中，我认为原生编译会很有趣有三个主要原因。

应用程序启动时间
这可能不完全是Java的错。我们正在使用Spring Boot，启动速度非常慢。我通常必须调整我的 Kubernetes 就绪探测，使其在启动 Pod 后不要早于 20 秒进行检查。这适用于一个非常小的应用程序 - 500 行代码。

内存占用
根据我的经验，您不希望为Spring Boot应用程序提供少于512MB的内存。否则，可能需要几分钟才能启动。虽然Java，尤其是JVM开销是罪魁祸首，但这也是一个框架问题。众所周知，春天非常臃肿，并且使用了很多反射。

应用程序大小
Java 应用程序容器的大小是另一个问题。这很烦人，但并不重要。我能找到的最小的JRE是~65MB大（基于阿尔卑斯山的openJDK）。如果你使用 Spring Boot，你至少会有一个 ~40MB 的大胖罐子用于你的应用程序。如果你的应用更大，它显然会更多。每个容器至少为 100MB。请注意，Docker 映像的 JRE 层可能会被多个 Docker 映像重用，因此对于应用的每个映像，它并不是真正的 100MB+。虽然我认为在 2018 年拥有 100MB+ 大型 hello world 应用程序肯定是可以忍受的，但如果我可以拥有一个 6MB 的 Go 二进制文件，那就太弱了。

GraalVM AOT 编译可能会改善这种情况。我希望启动时间几乎是即时的，不需要JVM，并且应用程序大小会大大减小。GraalVM 有一些严重的局限性，因为 JVM 的几个功能不能很好地与静态编译配合使用。
完整列表可以在这里找到。文档在这里非常清楚：动态类加载是受支持，将来也不会受支持。相反，编译器会分析代码并将所有必需的类编译到二进制文件中。结合反思，这成为当前Java生态系统的噩梦。许多库和框架使用反射来动态实例化类。GraalVM 不能很好地处理这个问题，在许多情况下，必须提供额外的编译器配置。其中一个原因是，对 Class.forName（） 的调用可能基于运行时信息。一个非常简单的例子：
if (someVariable) {
    Class.forName("SomeClazz")
    ...
}
由于someVariable的值在编译时是未知的，编译器无法知道是否包含“SomeClazz”。更不用说它只是一个字符串，编译器必须在编译时在类路径上搜索这个类。如果编译器决定包含此类，它将这样做，并在找不到该类时抛出错误。那很好。但是，这只是尽力而为。不能保证在编译时包含所有必需的类 - 这意味着类可能会丢失，并且在实例化时会引发运行时错误。还有更多的限制，要完整参考，请转到GraalVM的文档。
作为概念证明，我正在寻找一个没有过度使用 反射的休息库。显然这不是弹簧靴——我选择了 javalin.io。它只是码头顶部的一个休息图书馆，仅此而已。

标签：java,graalvm,构建,编译器,Kubernetes,JRE
来源：

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。