市面上可供選擇的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上執行了測試)。此功能可能會大大提高性能。

原文地址：https://technology.amis.nl/2018/11/23/comparing-jvm-performance-zulu-openjdk-openjdk-oracle-jdk-graalvm-ce/#prettyPhoto