市面上可供選擇的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
本文作者Maarten Smeets，由方圓翻譯。轉載本文請註明出處，歡迎更多小夥伴加入翻譯及投稿文章的行列，詳情請戳公眾號菜單「聯繫我們」。
GIAC全球互聯網架構大會深圳站將於2019年6月舉行，屆時將有Java專題深入探討相關話題，敬請期待。參考閱讀：
高可用架構
改變互聯網的構建方式
長按二維碼 關注「高可用架構」公眾號
閱讀更多 高可用架構 的文章
