市面上可供选择的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对数据可视化：

由于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</pre>
<pre class="graf graf--pre">docker-compose -f docker-compose-jdks.yml up

你可以可以访问:

8080端口的haproxy

9090端口的Prometheus

3000端口的Grafana

需要配置Grafana访问Prometheus的数据

接下来配置Grafana中的dashboard:

接下来，您可以对（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上执行了测试）。此功能可能会大大提高性能。

原文地址：

本文作者Maarten Smeets，由方圆翻译。转载本文请注明出处，欢迎更多小伙伴加入翻译及投稿文章的行列，详情请戳公众号菜单「联系我们」。GIAC全球互联网架构大会深圳站将于2019年6月举行，届时将有Java专题深入探讨相关话题，敬请期待。

参考阅读：

技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。

高可用架构

改变互联网的构建方式

长按二维码 关注「高可用架构」公众号