大家好！ 这是 Quarkus 系列文章的第二篇文章 - 今天我们将讨论本机编译。
是一个专门为 。 虽然这里肯定还有很多工作要做，但我们在很多方面都做了很多出色的工作，包括优化 JVM 和许多框架。 Quarkus 吸引了开发人员越来越多兴趣的功能之一是其全面、无缝的方法，可以将 Java 代码转换为特定操作系统的可执行文件（所谓的“本机编译”），类似于 C 和 C++，其中这种编译通常发生在构建、测试和部署周期结束时。
虽然本机编译很重要（正如我们将在下面展示的那样），但应该注意的是，Quarkus 在最常见的 Java 机器 OpenJDK Hotspot 上运行得非常好，这要归功于我们在整个堆栈中实现的性能改进。 因此，本机编译应该被视为一个额外的好处，可以根据需要或需要使用。 事实上，Quarkus 在本机镜像方面严重依赖 OpenJDK。 而受到开发人员热烈欢迎的开发模式，由于 Hotspot 中实现的动态代码执行的高级功能，确保了几乎即时的更改测试。 此外，在创建原生GraalVM镜像时，会使用OpenJDK类库和HotSpot功能。
那么，如果一切都已经完美优化，为什么还需要本机编译呢？ 下面我们将尝试回答这个问题。
让我们从显而易见的事情开始：红帽在项目开发过程中优化 JVM、堆栈和框架方面拥有丰富的经验 ， 包括：
- 第一个在平台上云中工作的应用服务器 .
- 第一个在计算机上运行的应用程序服务器 .
- 第一个运行的应用程序服务器 .
- 一系列在设备上运行的项目 .
多年来，我们一直在应对在云中和资源受限设备（即物联网）上运行 Java 应用程序的挑战，并学会了在性能和内存优化方面充分利用 JVM。 与许多其他人一样，我们长期以来一直致力于 Java 应用程序的本机编译 , , 乃至 我们很清楚这种方法的优点和缺点（例如，在“构建一次 - 随处运行”的普遍性与编译后的应用程序更小且运行速度更快之间进行选择的困境）。
为什么考虑这些利弊很重要？ 因为在某些情况下它们的比例变得决定性：
- 例如，在无服务器/事件驱动的环境中 （硬或软）实时，以便有时间响应事件。 与长期持久服务不同，冷启动的持续时间会显着增加请求的响应时间。 JVM 仍然需要大量的时间来启动，虽然在某些情况下可以通过纯硬件方法来减少这一时间，但 5 秒和 XNUMX 毫秒之间的差异可能是生与死的差异。 是的，在这里您可以尝试创建 Java 机器的热储备（例如，我们使用 ），但这本身并不能保证在负载扩展时有足够的 JVM 来处理请求。 从经济角度来看，这可能不是最正确的选择。
- 此外，还有另一个经常出现的方面：多租户。 尽管 JVM 的功能已经非常接近操作系统，但它们仍然无法完成我们在 Linux 中习惯的操作——隔离进程。 因此，一个线程的失败可能会导致整个Java机器瘫痪。 许多人试图通过为每个用户的应用程序专用一个单独的 JVM 来解决这个缺点，以最大程度地减少故障的后果。 这是非常合乎逻辑的，但不太适合缩放。
- 另外，对于面向云的应用，一个重要指标是主机上的服务密度。 过渡到方法论 、微服务和 Kubernetes 增加了每个应用程序的 Java 机器数量。 也就是说，一方面，所有这些都提供了弹性和可靠性，但同时服务方面的基础内存消耗也增加了，其中一些费用并不总是严格必要的。 当最终映像仅包含服务实际使用的框架部分（包括 JDK 本身）时，静态编译的可执行文件在这里受益于各种优化技术，例如低级死代码消除。 因此，Quarkus 原生编译有助于在不影响安全性的情况下将服务实例密集地放置在主机上。
其实，从 Quarkus 项目参与者的角度来看，上述论点已经足以理解原生编译的合理性了。 然而，还有另一个非技术性但也是重要的原因：近年来，许多程序员和开发公司已经放弃了 Java，转而采用新的编程语言，他们认为 Java 及其 JVM、堆栈和框架已经变得太糟糕了。内存消耗大、速度太慢等等。
然而，使用同一个工具解决任何问题的习惯是 。 有时最好退后一步，寻找其他东西。 如果 Quarkus 能让人们停下来思考，那么这对整个 Java 生态系统都有好处。 Quarkus 代表了如何构建更高效的应用程序的创新观点，使 Java 与无服务器等新应用程序架构更加相关。 此外，由于其可扩展性，Quarkus 将有望拥有一个完整的 Java 扩展生态系统，从而显着增加支持开箱即用的应用程序中的本机编译的框架数量。
来源： habr.com