共計 3199 個字符，預計需要花費 8 分鐘才能閱讀完成。

這篇文章將為大家詳細講解有關 Oracle,Open JDK 等四大 JVM 性能對比的示例分析，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

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

關于“Oracle,Open JDK 等四大 JVM 性能對比的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。