是否值得付费？Oracle,Open JDK等四大JVM性能全面对比

是否值得付费？***,Open JDK等四大JVM性能全面对比

市面上可供选择的JVM发行版还是有不少的。选择合适的JVM需要考虑不同的因素。性能是其中一个重要的因素。靠谱的性能研究是很困难的。在本文中，我创建了一个测试，在不同的JVM上执行对比测试。测试程序包括Spring Boot REST应用，使用Prometheus监控JVM并使用Grafana可视化。下图是示意图。除了soapui外，所有东西都在docker容器中运行。

隔离干扰因素

为进程分配特定CPU和内存

同环境测试

您如何确保所有测试都在完全相同的情况下进行? 当我针对JVM运行测试而明天再次运行相同的测试场景时，我的结果会有所不同。 这可能有各种原因，例如不同的CPU会占用工作负载，而且这些CPU也忙于处理其他事情，或者我在主机或客户操作系统中运行不同的后台进程。 即使***测试单个JVM并在测试之后测试另一个JVM，结果也无法比较。 例如，我正在使用Prometheus收集数据。 在第二次运行期间，Prometheus数据库可能会存储更多数据。 这可能会导致添加新数据的速度变慢，这可能会影响第二个JVM性能指标。 这个例子虽然可能相当牵强，但您可以采取措施排除其他因素。 这是我选择同时执行所有测试的原因。

setup

由于GraalVM目前仅作为JDK 8版本提供，因此其他JVM也使用JDK 8。 当容器运行时，可以通过访问执行器url来检查JVM版本：localhost:8080/actuator/env

或者使用如下命令:

docker exec -it store/***/serverjre:8 java -version

使用的JVM版本如下：

GraalVM CE rc9 (8u192)OpenJDK 8u191Zulu 8u192*** JDK 8u181

开始测试

可以在这里下载代码，然后运行命令：

sh ./buildjdkcontainers.sh

你可以可以访问:

8080端口的haproxy9090端口的Prometheus3000端口的Grafana

需要配置Grafana访问Prometheus的数据

接下来配置Grafana中的dashboard:

操作系统差异

不同Docker镜像之间使用的OS不同。 操作系统可通过以下方式确定：

docker exec -it store/***/serverjre:8 cat /etc/*-releaseazul/zulu-openjdk:8 used Ubuntu 18.04***/graalvm-ce:1.0.0-rc9 used *** Linux Server 7.5openjdk:8 used Debian GNU/Linux 9store/***/serverjre:8 used *** Linux Server 7.5

我认为这不会对JVM运行产生太大的影响。***JDK和Graalvm使用相同的操作系统。

测试结果

使用JVM dashboard，可以轻松区分特定的差异区域，以便进一步研究它们。

cpu使用

GraalVM在测试期间总体CPU使用率***。 *** JDK的CPU使用率***。

响应时间

整体GraalVM的响应时间最短，OpenJDK***，紧随*** JDK和Zulu。 平均而言，OpenJDK与GraalVM之间的差异约为30%。

垃圾回收

GraalVM加载了比其他JDK更多的类。 OpenJDK加载最少的类。 GraalVM和OpenJDK之间的差异大约是25%。 尚未确定这是否是GraalVM的固定开销，或者与所使用的类的数量成比例。

这些额外的类可能会导致垃圾收集期间的延迟(尽管这种相关性可能不一定是因果关系)。 GraalVM的的GC暂停时间确实最长。

下面是GC暂停时间总和的图表。 由于GraalVM中的分配失败导致了最长的GC暂停时间(顶部的一行)。

内存使用

JVM内存使用情况很有意思。 如上图所示，OpenJDK JVM使用的内存堆垛。 GraalVM和Zulu的垃圾收集行为似乎相似，但GraalVM具有更高的内存使用率。 *** JDK垃圾收集并不频繁。 在查看平均值时，OpenJDK JVM使用***内存，而Zulu使用最少内存。 在较长时间内衡量时，*** 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使用的内存最少。与*** JDK和OpenJDK相比，Zulu OpenJDK和GraalVM的内存使用更稳定。

当然，由于GraalVM相对较新，Micrometer提供的指标可能无法正确显示实际吞吐量和资源使用情况。也可能是我的设置导致这种差异。我通过查看不同情况下的结果来排除第二个问题。

如果您想使用GraalVM的多语言功能，那么其他JVM无此功能。GraalVM也提供了本地编译选项(我在同一个JAR上执行了测试)。此功能可能会大大提高性能。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。