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

-Xmx和-XX：MaxMetaspaceSize

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

堆大小在影響應(yīng)用性能和所需物理硬件需求。這帶來(lái)了一個(gè)問(wèn)題，我的應(yīng)用程序正確的堆大小是多少？我應(yīng)該為應(yīng)用程序分配大堆大小還是小堆大小？答案是：取決于需求和預(yù)算。

將-Xms和-Xmx設(shè)置為相同值的會(huì)提高JVM性能

元空間是將存儲(chǔ)JVM的元數(shù)據(jù)定義（例如類定義，方法定義）的區(qū)域。默認(rèn)情況下，可用于存儲(chǔ)此元數(shù)據(jù)信息的內(nèi)存量是無(wú)限的（即受您的容器或計(jì)算機(jī)的RAM大小的限制）。您需要使用-XX：MaxMetaspaceSize參數(shù)來(lái)指定可用于存儲(chǔ)元數(shù)據(jù)信息的內(nèi)存量的上限。

-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將選擇默認(rèn)算法。在Java 8之前，Parallel GC是默認(rèn)的GC算法。從Java 9開(kāi)始，G1 GC是默認(rèn)的GC算法。

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

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

GC算法JVM參數(shù)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日志記錄

垃圾收集日志包含有關(guān)垃圾收集事件，回收的內(nèi)存，暫停時(shí)間段等信息，可以通過(guò)傳遞以下JVM參數(shù)來(lái)啟用垃圾收集日志：

從JDK 1到JDK 8：

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

從JDK 9及更高版本開(kāi)始：

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

Demo：

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

通常，GC日志用于調(diào)整垃圾回收性能。但是，GC日志包含重要的微觀指標(biāo)。這些指標(biāo)可用于預(yù)測(cè)應(yīng)用程序的可用性和性能特征。在本文中將重點(diǎn)介紹一種這樣的標(biāo)尺：GC吞吐量。GC吞吐量是您的應(yīng)用程序在處理客戶交易中花費(fèi)的時(shí)間與它在處理GC活動(dòng)中花費(fèi)的時(shí)間之比。假設(shè)您的應(yīng)用程序的GC吞吐量為98％，則意味著應(yīng)用程序?qū)⑵?8％的時(shí)間用于處理客戶活動(dòng)，其余2％用于GC活動(dòng)。

現(xiàn)在，讓我們看一個(gè)健康的JVM的堆使用情況圖：

您會(huì)看到一個(gè)完美的鋸齒圖案。您會(huì)注意到，當(dāng)運(yùn)行Full GC（紅色三角形）時(shí)，內(nèi)存利用率將一直下降到最低。

現(xiàn)在，讓我們看一下有問(wèn)題的JVM的堆使用情況圖：

您可以注意到，在圖表的右端，即使GC反復(fù)運(yùn)行，內(nèi)存利用率也沒(méi)有下降。這是一個(gè)典型的內(nèi)存泄漏跡象，表明該應(yīng)用程序正在存在某種內(nèi)存問(wèn)題。

如果您仔細(xì)觀察一下該圖，您會(huì)發(fā)現(xiàn)重復(fù)的完整GC開(kāi)始在上午8點(diǎn)左右開(kāi)始。但是，該應(yīng)用程序僅在上午8:45左右開(kāi)始獲取OutOfMemoryError。到上午8點(diǎn)，該應(yīng)用程序的GC吞吐量約為99％。但是，在上午8點(diǎn)之后，GC吞吐量開(kāi)始下降到60％。因?yàn)楫?dāng)重復(fù)的GC運(yùn)行時(shí)，該應(yīng)用程序?qū)⒉粫?huì)處理任何客戶交易，而只會(huì)進(jìn)行GC活動(dòng)。

-XX：+ HeapDumpOnOutOfMemoryError，-XX：HeapDumpPath

OutOfMemoryError是一個(gè)嚴(yán)重的問(wèn)題，它將影響您的應(yīng)用程序的可用性和性能。要診斷OutOfMemoryError或任何與內(nèi)存相關(guān)的問(wèn)題，必須在應(yīng)用程序開(kāi)始遇到OutOfMemoryError的那一刻或一瞬間捕獲堆轉(zhuǎn)儲(chǔ)。由于我們不知道何時(shí)會(huì)拋出OutOfMemoryError，因此很難在拋出時(shí)左右的正確時(shí)間手動(dòng)捕獲堆轉(zhuǎn)儲(chǔ)。但是，可以通過(guò)傳遞以下JVM參數(shù)來(lái)自動(dòng)化捕獲堆轉(zhuǎn)儲(chǔ)：

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

在-XX：HeapDumpPath中，需要指定堆轉(zhuǎn)儲(chǔ)所在的文件路徑。傳遞這兩個(gè)JVM參數(shù)時(shí)，將在拋出OutOfMemoryError時(shí)自動(dòng)捕獲堆轉(zhuǎn)儲(chǔ)并將其寫(xiě)入定義的文件路徑。例：

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

一旦捕獲了堆轉(zhuǎn)儲(chǔ)，就可以使用HeapHero和EclipseMAT之類的工具來(lái)分析堆轉(zhuǎn)儲(chǔ)。

-Xss

每個(gè)應(yīng)用程序?qū)⒕哂袛?shù)十，數(shù)百，數(shù)千個(gè)線程。每個(gè)線程都有自己的堆棧。在每個(gè)線程的堆棧中，存儲(chǔ)以下信息：

• 當(dāng)前執(zhí)行的方法/功能
• 原始數(shù)據(jù)類型
• 變量
• 對(duì)象指針
• 返回值。

他們每個(gè)都消耗內(nèi)存。如果它們的使用量超出某個(gè)限制，則會(huì)引發(fā)StackOverflowError。可以通過(guò)傳遞-Xss參數(shù)來(lái)增加線程的堆棧大小限制。例：

-Xss256k

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

假設(shè)您的應(yīng)用程序有500個(gè)進(jìn)程，然后-Xss值為2Mb，則您的線程將消耗1000Mb的內(nèi)存。另一方面，如果您僅將-Xss分配為256kb，那么您的線程將僅消耗125Mb的內(nèi)存。每個(gè)JVM將節(jié)省875Mb內(nèi)存。

注意：線程是在堆（即-Xmx）之外創(chuàng)建的，因此這1000Mb將是您已經(jīng)分配的-Xmx值的補(bǔ)充。

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

現(xiàn)代應(yīng)用程序使用多種協(xié)議（即SOAP，REST，HTTP，HTTPS，JDBC，RMI）與遠(yuǎn)程應(yīng)用程序連接。有時(shí)遠(yuǎn)程應(yīng)用程序可能需要很長(zhǎng)時(shí)間才能做出響應(yīng)，有時(shí)它可能根本不響應(yīng)。

如果沒(méi)有正確的超時(shí)設(shè)置，并且遠(yuǎn)程應(yīng)用程序的響應(yīng)速度不夠快，則您的應(yīng)用程序線程/資源將被卡住。遠(yuǎn)程應(yīng)用程序無(wú)響應(yīng)可能會(huì)影響您的應(yīng)用程序的可用性。它可以使您的應(yīng)用程序停止磨削。為了保護(hù)應(yīng)用程序的高可用性，應(yīng)配置適當(dāng)?shù)某瑫r(shí)設(shè)置。

您可以在JVM級(jí)別傳遞這兩個(gè)強(qiáng)大的超時(shí)網(wǎng)絡(luò)屬性，這些屬性可以全局適用于所有使用java.net.URLConnection的協(xié)議處理程序：

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

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

注意，默認(rèn)情況下，這兩個(gè)屬性的值為-1，這表示未設(shè)置超時(shí)。

---

• 鄭重聲明：文章首發(fā)于公眾號(hào)“FunTester”，歡迎關(guān)注交流，禁止第三方（騰訊云除外）轉(zhuǎn)載、發(fā)表。

技術(shù)類文章精選

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

無(wú)代碼文章精選

• 寫(xiě)給所有人的編程思維
• JSON基礎(chǔ)
• 2020年Tester自我提升
• 自動(dòng)化新手要避免的坑（上）
• 自動(dòng)化新手要避免的坑（下）
• 如何成為全棧自動(dòng)化工程師
• 選擇手動(dòng)測(cè)試還是自動(dòng)化測(cè)試？
• 自動(dòng)化測(cè)試項(xiàng)目為何失敗
• 簡(jiǎn)化測(cè)試用例

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。