本文将详细解释Oracle和OpenJDK等四种JVM性能比较的实例分析。边肖觉得挺实用的，就分享给大家参考。希望你看完这篇文章能有所收获。
市场上仍然有许多JVM发行版。选择合适的JVM需要考虑不同的因素。性能是重要因素之一。可靠的性能研究非常困难。在本文中，我创建了一个测试来对不同的JVM进行比较测试。测试程序包括Spring Boot REST应用程序，该应用程序使用普罗米修斯来监控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，结果也无法比较。例如，我正在使用普罗米修斯收集数据。在第二次运行期间，普罗米修斯数据库可能会存储更多的数据。这可能会降低添加新数据的速度，这可能会影响第二个JVM性能指标。虽然这个例子可能有些牵强，但你可以采取措施消除其他因素。这就是为什么我选择同时执行所有测试。
setup
我的环境包括一个docker-compose文件，它允许我轻松启动运行在不同JVM上的四个Spring Boot应用程序。在4 JDK之前，我添加了一个haproxy实例来平衡负载。这是为了确保不同测试之间没有与时间相关的差异，并且所有JVM同时处于相同的负载下。
为了监控结果，我使用千分尺来确保普罗米修斯可以读取JVM性能指标。我用Grafana来可视化数据：https://grafana.com/dashboards/4701
由于GraalVM目前仅作为JDK 8版本提供，其他JVM也使用JDK 8。当容器运行时，您可以通过访问执行器URL:localhost :8080/actuator/env来检查JVM版本。
或者使用以下命令：
docker exec -it商店/Oracle/server Jr e :8 Java-版本
使用的JVM版本如下：
GraalVM CE rc9 (8u192)
OpenJDK 8u191
祖鲁8u192
甲骨文JDK 8u181
开始测试
您可以在此下载代码，然后运行命令：
先令/buildjdkcontainers.sh
docker-compose-f docker-compose-jdks . yml up
是的，你可以访问：
080端口的Haproxy
090终端
口的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性能对比的示例分析”这篇文章就分享到这里了，希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/150142.html