圍繞垃圾收集和內存，您可以將600多個參數傳遞給JVM。如果包括其他方面，則JVM參數總數將很容易超過1000+。任何人都無法消化和理解太多的論據。在本文中，重點介紹了七個重要的JVM參數，在Java性能測試中起著非常重要的作用。

-Xmx和-XX：MaxMetaspaceSize

-Xmx可能是最重要的JVM參數。-Xmx定義要分配給應用程序的最大堆大小。。您可以這樣定義應用程序的堆大小：-Xmx2g。

堆大小在影響應用性能和所需物理硬件需求。這帶來了一個問題，我的應用程序正確的堆大小是多少？我應該為應用程序分配大堆大小還是小堆大小？答案是：取決于需求和預算。

將-Xms和-Xmx設置為相同值的會提高JVM性能

元空間是將存儲JVM的元數據定義（例如類定義，方法定義）的區域。默認情況下，可用于存儲此元數據信息的內存量是無限的（即受您的容器或計算機的RAM大小的限制）。您需要使用-XX：MaxMetaspaceSize參數來指定可用于存儲元數據信息的內存量的上限。

-XX:MaxMetaspaceSize=256m

GC算法

OpenJDK中有7種不同的GC算法：

• Serial GC
• Parallel GC
• Concurrent Mark & Sweep GC
• G1 GC
• Shenandoah GC
• Z GC
• Epsilon GC

如果您未明確指定GC算法，那么JVM將選擇默認算法。在Java 8之前，Parallel GC是默認的GC算法。從Java 9開始，G1 GC是默認的GC算法。

GC算法的選擇對于確定應用程序的性能起著至關重要的作用。根據我們的研究，我們正在使用Z GC算法觀察到出色的性能結果。如果使用JVM 11+，則可以考慮使用Z GC算法（即-XX：+ UseZGC）。

下表總結了激活每種垃圾收集算法所需傳遞的JVM參數。

GC算法JVM參數Serial GC-XX：+ UseSerialGCParallel GC-XX：+ UseParallelGCConcurrent Market & Sweep (CMS) GC-XX：+ UseConcMarkSweepGCG1 GC-XX：+ UseG1GCShenandoah GC-XX：+使用ShenandoahGCZ GC-XX：+ UseZGCEpsilon GCGC -XX：+ UseEpsilonGC

啟用GC日志記錄

垃圾收集日志包含有關垃圾收集事件，回收的內存，暫停時間段等信息，可以通過傳遞以下JVM參數來啟用垃圾收集日志：

從JDK 1到JDK 8：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:{file-path}

從JDK 9及更高版本開始：

-Xlog:gc*:file={file-path}

Demo：

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/opt/workspace/myAppgc.log -Xlog:gc*:file=/opt/workspace/myAppgc.log

通常，GC日志用于調整垃圾回收性能。但是，GC日志包含重要的微觀指標。這些指標可用于預測應用程序的可用性和性能特征。在本文中將重點介紹一種這樣的標尺：GC吞吐量。GC吞吐量是您的應用程序在處理客戶交易中花費的時間與它在處理GC活動中花費的時間之比。假設您的應用程序的GC吞吐量為98％，則意味著應用程序將其98％的時間用于處理客戶活動，其余2％用于GC活動。

現在，讓我們看一個健康的JVM的堆使用情況圖：

您會看到一個完美的鋸齒圖案。您會注意到，當運行Full GC（紅色三角形）時，內存利用率將一直下降到最低。

現在，讓我們看一下有問題的JVM的堆使用情況圖：

您可以注意到，在圖表的右端，即使GC反復運行，內存利用率也沒有下降。這是一個典型的內存泄漏跡象，表明該應用程序正在存在某種內存問題。

如果您仔細觀察一下該圖，您會發現重復的完整GC開始在上午8點左右開始。但是，該應用程序僅在上午8:45左右開始獲取OutOfMemoryError。到上午8點，該應用程序的GC吞吐量約為99％。但是，在上午8點之后，GC吞吐量開始下降到60％。因為當重復的GC運行時，該應用程序將不會處理任何客戶交易，而只會進行GC活動。

-XX：+ HeapDumpOnOutOfMemoryError，-XX：HeapDumpPath

OutOfMemoryError是一個嚴重的問題，它將影響您的應用程序的可用性和性能。要診斷OutOfMemoryError或任何與內存相關的問題，必須在應用程序開始遇到OutOfMemoryError的那一刻或一瞬間捕獲堆轉儲。由于我們不知道何時會拋出OutOfMemoryError，因此很難在拋出時左右的正確時間手動捕獲堆轉儲。但是，可以通過傳遞以下JVM參數來自動化捕獲堆轉儲：

-XX：+ HeapDumpOnOutOfMemoryError和-XX：HeapDumpPath = {HEAP-DUMP-FILE-PATH}

在-XX：HeapDumpPath中，需要指定堆轉儲所在的文件路徑。傳遞這兩個JVM參數時，將在拋出OutOfMemoryError時自動捕獲堆轉儲并將其寫入定義的文件路徑。例：

-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/crashes/my-heap-dump.hprof

一旦捕獲了堆轉儲，就可以使用HeapHero和EclipseMAT之類的工具來分析堆轉儲。

-Xss

每個應用程序將具有數十，數百，數千個線程。每個線程都有自己的堆棧。在每個線程的堆棧中，存儲以下信息：

• 當前執行的方法/功能
• 原始數據類型
• 變量
• 對象指針
• 返回值。

他們每個都消耗內存。如果它們的使用量超出某個限制，則會引發StackOverflowError。可以通過傳遞-Xss參數來增加線程的堆棧大小限制。例：

-Xss256k

如果將此-Xss值設置為一個很大的數字，則內存將被阻塞并浪費。假設您將-Xss值指定為2mb，而只需要256kb，那么您將浪費大量的內存。

假設您的應用程序有500個進程，然后-Xss值為2Mb，則您的線程將消耗1000Mb的內存。另一方面，如果您僅將-Xss分配為256kb，那么您的線程將僅消耗125Mb的內存。每個JVM將節省875Mb內存。

注意：線程是在堆（即-Xmx）之外創建的，因此這1000Mb將是您已經分配的-Xmx值的補充。

-Dsun.net.client.defaultConnectTimeout和-Dsun.net.client.defaultReadTimeout

現代應用程序使用多種協議（即SOAP，REST，HTTP，HTTPS，JDBC，RMI）與遠程應用程序連接。有時遠程應用程序可能需要很長時間才能做出響應，有時它可能根本不響應。

如果沒有正確的超時設置，并且遠程應用程序的響應速度不夠快，則您的應用程序線程/資源將被卡住。遠程應用程序無響應可能會影響您的應用程序的可用性。它可以使您的應用程序停止磨削。為了保護應用程序的高可用性，應配置適當的超時設置。

您可以在JVM級別傳遞這兩個強大的超時網絡屬性，這些屬性可以全局適用于所有使用java.net.URLConnection的協議處理程序：

sun.net.client.defaultConnectTimeout：指定建立到主機的連接的超時（以毫秒為單位）。例如，對于HTTP連接，它是與HTTP服務器建立連接時的超時。當建立與資源的連接時，sun.net.client.defaultReadTimeout指定從輸入流讀取時的超時（以毫秒為單位）。 例如，如果您要將這些屬性設置為2秒：

-Dsun.net.client.defaultConnectTimeout=2000 -Dsun.net.client.defaultReadTimeout=2000

注意，默認情況下，這兩個屬性的值為-1，這表示未設置超時。

---

• 鄭重聲明：文章首發于公眾號“FunTester”，歡迎關注交流，禁止第三方（騰訊云除外）轉載、發表。

技術類文章精選

• Linux性能監控軟件netdata中文漢化版
• 性能測試框架第三版
• 圖解HTTP腦圖
• 性能測試中圖形化輸出測試數據
• 壓測中測量異步寫入接口的延遲
• 多種登錄方式定量性能測試方案
• JMeter吞吐量誤差分析
• 多項目登錄互踢測試用例

無代碼文章精選

• 寫給所有人的編程思維
• JSON基礎
• 2020年Tester自我提升
• 自動化新手要避免的坑（上）
• 自動化新手要避免的坑（下）
• 如何成為全棧自動化工程師
• 選擇手動測試還是自動化測試？
• 自動化測試項目為何失敗
• 簡化測試用例

總結

以上是生活随笔為你收集整理的jvm 参数_6个重要的JVM性能参数的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。