共计 3199 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Oracle,Open JDK 等四大 JVM 性能对比的示例分析，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
市面上可供选择的 JVM 发行版还是有不少的。选择合适的 JVM 需要考虑不同的因素。性能是其中一个重要的因素。靠谱的性能研究是很困难的。在本文中，我创建了一个测试，在不同的 JVM 上执行对比测试。测试程序包括 Spring Boot REST 应用，使用 Prometheus 监控 JVM 并使用 Grafana 可视化。下图是示意图。除了 soapui 外，所有东西都在 docker 容器中运行。
隔离干扰因素
如何确定没有别的因素干扰你的设施。我们可以通过尝试隔离分配给流程的资源来实现。例如，分配专用 CPU 和固定数量的内存。 我还进行了几项测试，这些测试将资源限制放在负载均衡器，监控软件和可视化软件上 (为这些资源分配不同的 CPU 和内存)。 为进程分配特定资源(使用 docker-compose v2 cpuset 和内存参数) 似乎不会对单个进程负载和响应时间的度量产生很大影响。 我还比较了启动，负载和无负载情况。在这些不同情况下，测试结果没有很大变化。
为进程分配特定 CPU 和内存
使用 docker-compose 无法为进程配置特定 CPU。docker-compose v3 不支持为进程分配特定的 CPU，也不支持分配资源约束。 您可以想象在潜在的多主机环境中分配特定 CPU 并非易事。因此，我将 docker-compose 文件迁移回 v2，该版本允许分配特定的 CPU。 可以用于监控软件，这些 CPU 和 JVM 使用的 CPU 隔离开。我使用了 taskset 命令。
同环境测试
您如何确保所有测试都在完全相同的情况下进行? 当我针对 JVM 运行测试而明天再次运行相同的测试场景时，我的结果会有所不同。 这可能有各种原因，例如不同的 CPU 会占用工作负载，而且这些 CPU 也忙于处理其他事情，或者我在主机或客户操作系统中运行不同的后台进程。 即使 *** 测试单个 JVM 并在测试之后测试另一个 JVM，结果也无法比较。例如，我正在使用 Prometheus 收集数据。 在第二次运行期间，Prometheus 数据库可能会存储更多数据。这可能会导致添加新数据的速度变慢，这可能会影响第二个 JVM 性能指标。 这个例子虽然可能相当牵强，但您可以采取措施排除其他因素。这是我选择同时执行所有测试的原因。
setup
我的环境包括一个 docker-compose 文件，它允许我轻松启动 4 个在不同 JVM 上运行 Spring Boot 应用程序。 在 4 个 JDK 的之前，我加了一个 haproxy 实例来进行负载均衡。这是为了确保不同的测试之间没有时间相关的差异，保证所有 JVM 都同时处于相同的负载下。
为了监控结果，我使用了 Micrometer 保证 Prometheus 能够读取 JVM 性能指标。 我使用 Grafana 对数据可视化：https://grafana.com/dashboards/4701
由于 GraalVM 目前仅作为 JDK 8 版本提供，因此其他 JVM 也使用 JDK 8。 当容器运行时，可以通过访问执行器 url 来检查 JVM 版本：localhost:8080/actuator/env
或者使用如下命令:
docker exec -it store/oracle/serverjre:8 java -version
使用的 JVM 版本如下：
GraalVM CE rc9 (8u192)
OpenJDK 8u191
Zulu 8u192
Oracle JDK 8u181
开始测试
可以在这里下载代码，然后运行命令：
sh ./buildjdkcontainers.sh
docker-compose -f docker-compose-jdks.yml up
你可以可以访问:
8080 端口的 haproxy
9090 端口的 Prometheus
3000 端口的 Grafana
需要配置 Grafana 访问 Prometheus 的数据
接下来配置 Grafana 中的 dashboard:
接下来，您可以对 http://localhost:8080/hello(HTTP GET)执行负载测试，并在 Grafana 仪表板中查看结果。
操作系统差异
不同 Docker 镜像之间使用的 OS 不同。操作系统可通过以下方式确定：
docker exec -it store/oracle/serverjre:8 cat /etc/*-release
azul/zulu-openjdk:8 used Ubuntu 18.04
oracle/graalvm-ce:1.0.0-rc9 used Oracle Linux Server 7.5
openjdk:8 used Debian GNU/Linux 9
store/oracle/serverjre:8 used Oracle Linux Server 7.5
我认为这不会对 JVM 运行产生太大的影响。OracleJDK 和 Graalvm 使用相同的操作系统。
测试结果
使用 JVM dashboard，可以轻松区分特定的差异区域，以便进一步研究它们。
cpu 使用
GraalVM 在测试期间总体 CPU 使用率 ***。Oracle JDK 的 CPU 使用率 ***。
响应时间
整体 GraalVM 的响应时间最短，OpenJDK***，紧随 Oracle JDK 和 Zulu。 平均而言，OpenJDK 与 GraalVM 之间的差异约为 30%。
垃圾回收
GraalVM 加载了比其他 JDK 更多的类。OpenJDK 加载最少的类。GraalVM 和 OpenJDK 之间的差异大约是 25%。 尚未确定这是否是 GraalVM 的固定开销，或者与所使用的类的数量成比例。
这些额外的类可能会导致垃圾收集期间的延迟(尽管这种相关性可能不一定是因果关系)。GraalVM 的的 GC 暂停时间确实最长。
下面是 GC 暂停时间总和的图表。由于 GraalVM 中的分配失败导致了最长的 GC 暂停时间(顶部的一行)。
内存使用
JVM 内存使用情况很有意思。如上图所示，OpenJDK JVM 使用的内存堆垛。 GraalVM 和 Zulu 的垃圾收集行为似乎相似，但 GraalVM 具有更高的内存使用率。Oracle JDK 垃圾收集并不频繁。在查看平均值时，OpenJDK JVM 使用 *** 内存，而 Zulu 使用最少内存。在较长时间内衡量时，Oracle JDK 和 OpenJDK 的行为看起来不稳定，而 Zulu 和 GraalVM 看起来更稳定。
总结
在本次测试中，我使用 SOAP UI 对运行在 4 个不同 JVM 上的 Spring Boot Rest 程序进行了压力测试。我使用 Prometheus 轮询 JVM 实例(每 5s 轮训一次，用 Micrometer 生成数据)，并使用 Grafana 和 Prometheus 来显示数据。结果表明 GraalVM 不适合作为 OpenJDK 的替代品，因为它的表现更差，使用了更多资源，加载更多类而且垃圾收集时间更长。
GraalVM 加载的类更多
GraalVM 上的应用程序响应时间最慢
GraalVM 的 CPU 使用率 ***(响应时间最慢)
GraalVM 的 GC 时间最长
Zulu OpenJDK 使用的内存最少。与 Oracle JDK 和 OpenJDK 相比，Zulu OpenJDK 和 GraalVM 的内存使用更稳定。
当然，由于 GraalVM 相对较新，Micrometer 提供的指标可能无法正确显示实际吞吐量和资源使用情况。也可能是我的设置导致这种差异。我通过查看不同情况下的结果来排除第二个问题。
如果您想使用 GraalVM 的多语言功能，那么其他 JVM 无此功能。GraalVM 也提供了本地编译选项(我在同一个 JAR 上执行了测试)。此功能可能会大大提高性能。
关于“Oracle,Open JDK 等四大 JVM 性能对比的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
