阿里高级技术专家：“云原生编译，将 JVM 带入现代云世界”

最新推荐文章于 2024-06-11 14:33:13 发布

Java小吴吴

最新推荐文章于 2024-06-11 14:33:13 发布

阅读量260

点赞数

文章标签： java 面试数据结构 sqlite

本文链接：https://blog.csdn.net/m0_67788957/article/details/123639325

版权

随着 Java 的不断成熟，重要的是推动云优化功能，以提供更好的性能和更低的成本。

在整个行业中，公司正试图通过从他们在云中运行的实例中挤出更多的承载能力来控制失控的云成本。尤其是在 Java 领域，开发人员正试图将工作负载放入越来越小的实例中，并以最高效率利用服务器资源。依靠弹性水平扩展来处理流量高峰意味着 Java 工作负载必须快速启动并保持快速。但是JVM 的一些过时特性使得很难有效地利用云实例上的资源。

是时候重新想象 Java 如何在以云为中心的世界中运行了。我们首先探索如何通过将 JIT 工作负载卸载到云资源来优化编译。我们能否实现性能更高、预热时间更短的优化代码？

在这篇博客中，我们将看到：

当前 JIT 编译模型的起源
on-JVM JIT 编译的缺点
云原生编译如何影响性能、预热时间和计算资源

回顾 JIT 编译

今天的 Java JIT 编译模型可以追溯到 1990 年代。自 1990 年代以来发生了很多变化！但是有些东西，比如 Java JIT 编译模型，没有。我们可以做得更好。

首先，回顾一下 JIT 编译。当 JVM 启动时，它会在较慢的解释器中运行 Java 程序中已编译的可移植字节码，直到它能够识别“热”方法的概要文件以及它们是如何运行的。然后，JIT 编译器将这些方法编译成针对当前使用模式高度优化的机器代码。它运行该代码，直到优化被证明是错误的。在这种情况下，我们得到了一个去优化，优化的代码被抛出，该方法再次在解释器中运行，直到可以产生一个新的优化方法。当 JVM 关闭时，所有配置文件信息和优化方法都被丢弃，下次运行时，整个过程从头开始。

在 90 年代创建 Java 时，还没有我们可以随意上下旋转的连接、弹性资源的“魔法云”。因此，让 JVM（包括 JIT 编译器）完全封装和自力更生是一个合乎逻辑的选择。

那么这种方法的缺点是什么？好吧…

JIT 编译器必须与执行应用程序逻辑的线程共享资源。这意味着有多少资源可以用于优化，限制了这些优化的速度和有效性。例如，Azul Platform Prime 的 Falcon JIT 编译器的最高优化级别生成的代码可以在单个方法和工作负载上快 50%-200%。然而，在资源受限的机器上，由于资源限制，如此高的优化级别可能不实用。
您只需要在程序生命周期的一小部分中进行 JIT 编译的资源。但是，使用 on-JVM JIT 编译时，您必须永远保留容量。
在 JVM 生命周期之初，与 JIT 相关的 CPU 和内存使用量激增可能会对负载均衡器、Kubernetes CPU 节流和部署拓扑的其他部分造成严重破坏。
JVM 没有过去运行的记忆。即使 JVM 正在运行它之前运行过一百次的工作负载，它也必须像第一次一样在解释器中从头开始运行它。
JVM 不知道运行相同程序的其他节点。每个 JVM 都会根据其流量构建一个配置文件，但可以通过聚合数百个运行相同代码的 JVM 的经验来构建一个性能更高的配置文件。

将 JIT 编译卸载到云端

今天，我们确实拥有一个“神奇的云”资源，我们可以使用它来卸载可以在其他地方更有效地完成的 JVM 进程。这就是我们构建 Cloud Native Compiler 的原因，它是可扩展 JIT 编译资源的专用服务，您可以使用它来预热 JVM。

Cloud-Native Compiler 作为 Kubernetes 集群在您的服务器中运行，无论是在本地还是在云中。因为它是可扩展的，所以您可以在需要时增加服务以在短时间内为 JIT 编译提供几乎无限的资源，然后在不需要时将其缩小到接近零。

在 Java 工作负载上使用云原生编译时：

客户端上的 CPU 消耗保持低且稳定。您不必为进行 JIT 编译而预留容量，并且可以调整实例的大小以证明运行应用程序逻辑的资源需求是合理的。
无论您的 JVM 客户端实例的容量如何，您都可以负担得起运行最激进的优化，从而获得最高的顶线性能。
由于更多可用线程，JIT 编译请求更多地并行运行，因此预热 JVM 的挂钟时间显着减少。

那么，它真的有区别吗？

请注意，当我们在资源极度受限的 2 vCore 机器上运行 finagle-http Renaissance 工作负载时会发生什么。进行更重的优化意味着花费更多的资源，正如 Azul Platform Prime 与本地 JIT 的长预热曲线所示。在进行云原生编译时，这种较长的预热时间可以降到与 OpenJDK 相同的水平，而优化的 Falcon 代码继续以更快的吞吐量运行。