截止到2020年五月，JVM中僅僅只是關于垃圾回收和內存相關的參數就已經超過600個。如果算上其他方面的參數，JVM相關的總參數能輕松超過1000個。參數太多了，弄得人很懵逼。在這邊文章中，我們只選取了7個比較重要，且有用的JVM參數來介紹。

-Xmx 和 -XX:MaxMetaspaceSize

-Xmx可能是最重要最常用的JVM參數了。-Xmx用來定義能分配給應用的最大堆空間大小。你可以像這樣使用：

-Xmx2g

堆空間大小直接決定著應用性能。但是隨之而來的問題是，對于一個應用，應該設置多大的堆空間是合理的？我應該為我的應用設置一個大的堆空間，還是一個相對較小的？答案是：“看情況”，這個問題，另開一篇文章專門探討。

這里只提示一點，將-Xmx和-Xms設置為相同，能獲得更好的性能。

元空間是對JVM規范中方法區的實現，用于存儲JVM中的元數據信息，比如類定義，方法定義等。在默認情況下，元空間使用的是本地內存空間，所以理論上講，元空間地址是沒有上限的，他受限于機器的內存大小，內存尋址空間大小等。可以通過以下參數來指定元空間的大小：

-XX:MaxMetaspaceSize=512m //設置元空間最大空間-XX:MetaspaceSize //初始元空間大小

對于-XX:MetaspaceSize來說，達到該值就會觸發垃圾收集進行類型卸載，同時GC會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過MaxMetaspaceSize時，適當提高該值。

另：除了上面兩個指定大小的選項以外，還有兩個與 GC 相關的屬性：

-XX:MinMetaspaceFreeRatio，在GC之后，最小的Metaspace剩余空間容量的百分比，減少為分配空間所導致的垃圾收集

-XX:MaxMetaspaceFreeRatio，在GC之后，最大的Metaspace剩余空間容量的百分比，減少為釋放空間所導致的垃圾收集

GC回收器類型

截止目前為止，在OpenJDK中，一共提供了7種類型的GC【這里注意區分一下GC回收器類型和GC回收算法】：

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

如果沒有特別的指定GC回收器，JVM會使用默認的，到Java8，Parallel GC是默認回收器，從Java9之后，G1 GC是默認的GC回收器。

使用何種GC回收器，對于應用的性能表現起著至關重要的作用。 從測試數據來看，Z GC有非常不錯的表現。如果你的應用運行在JVM11以上，我們建議優先考慮使用Z GC(-XX:+UseZGC)。

下表中列出了不同GC算法及其對應的開啟參數：

• Serial GC -XX:+UseSerialGC
• Parallel GC -XX:+UseParallelGC
• Concurrent Market & Sweep (CMS) GC -XX:+UseConcMarkSweepGC
• G1 GC -XX:+UseG1GC
• Shenandoah GC -XX:+UseShenandoahGC
• Z GC -XX:+UseZGC
• Epsilon GC -XX:+UseEpsilonGC

Enable GC Logging

GC日志中包含了包括垃圾回收事件，內存空間情況，時間間隔等等。可以使用下面的JVM參數來開啟GC日志。

JDK8及其之前：

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

JDK9及之后：

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

一個詳細例子：

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

一般情況下，GC日志主要用來調整GC性能。然而，GC日志中也包含了很多微觀指標。這些指標可用于預測應用程序的可用性和性能。在這里，我們只舉一個例子：“GC Throughput(GC吞吐量)”。GC吞吐量是應用程序處理應用事務所花費的時間與處理GC活動所花費的時間之比。比如應用的GC吞吐量是98%，這意味著應用程序將98%的時間花在處理應用活動上，剩下的2%花在GC活動上。

接下來看一個健康的JVM的堆使用圖：

你可以看到一個完美的鋸齒圖案。可以看到到，當運行完整的GC(紅色三角形)時，內存利用率下降到了底部。再來看一個有問題的JVM堆使用圖：

注意圖案的右側區域，及時GC不斷的運行，內存利用率仍然沒有明顯下降。這就是一個出現了內存問題的典型跡象。

當我們更仔細的分析這個圖片，我們可以看到，在8點左右的時間，完全GC開始重復出現，知道8點45左右，應用出現了OOM異常。8點之前，GC的吞吐量在99%左右，但是在8點之后，GC的吞吐量掉到了60%，因為大量重復GC的動作出現，讓應用已經沒有太多時間處理應用的正常事務。一種主動的措施，如果當發現GC吞吐量開始下降的時候，我們可以從負載平衡群中取出該JVM。這樣，出現問題的JVM就不會處理任何新的流量，可以最大限度地減少對客戶請求的影響。

可以使用GCeasy REST API實時監控GC的微觀數據，也可以使用gcviewer (https://github.com/chewiebug/GCViewer)離線分析GC日志文件。

-XX:+HeapDumpOnOutOfMemoryError, -XX:HeapDumpPath

OOM異常嚴重影響應用的可用性/性能SLA等級。要診斷OOM異常或任何與內存相關的問題，必須在應用程序開始遇到OOM之前的某一時刻或幾分鐘捕獲heap dump(堆轉儲文件)。由于我們不知道OOM何時出來，所以很難手動捕獲它。一般通過傳遞以下JVM參數來自動捕獲heap dump：

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

在-XX:HeapDumpPath中，我們設置一個堆轉儲文件地址。當這兩個參數傳遞給JVM之后，當拋出OOM的時候，heap dump會被自動捕獲并存儲在指定文件路徑上。

一般可以使用jhat、EclipseMAT分析heap dump。

-Xss

每個應用在運行時都會產生大量線程，每個線程擁有自己的棧空間。在每個線程棧中包含了以下內容：

• 當前正在執行的方法
• 原始數據類型
• 變量
• 對象指針
• 返回值

每一項都占用內存。如果內存占用超過一定限制，就會拋出StackOverflowError異常。可以使用-Xss參數來調整線程棧的大小。例如：

-Xss256k

如果設置-Xss過大，會造成內存的阻塞和浪費。例如，假設我們設置-Xss大小為2MB，但實際上，只需要256KB，就會造成非常大的內存浪費，而不僅僅只是字面量上的1792KB。假設應用一共有500個線程，當-Xss設置為2MB，線程會總共占用1000MB內存。而如果設置-Xss為256KB，實際總共只需要125MB內存空間，總共節約了875MB內存。所以，-Xss的設置會造成巨大的內存消耗差異。

我們建議先將-Xss設置為一個較小的值，比如256KB，并使用該設置完成回歸、性能和AB測試。如果在這個過程中遇到了StackOverflowError，再逐步提高該值即可，否則使用一個較小的值。

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

在一個應用中，常常會涉及到使用各種協議(SOAP, REST, HTTP, HTTPS, JDBC, RMI等)和第三方應用交互。有時候第三方應用會響應很慢，或者無響應。

在這種情況下，如果沒有一個合理的超時時間設置，如果遠端應用沒法及時響應，則會造成我們的應用線程/資源出現問題。遠程應用程序無響應會影響我們程序的可用性。所以，設置合理的超時時間是非常必要的。

你可以通過設置這兩個非常強大的網絡參數，在JVM層面上控制所有通過java.net.URLConnection建立的協議連接。

sun.net.client.defaultConnectTimeout：設置連接到主機的超時時間(毫秒)sun.net.client.defaultReadTimeout：與資源建立連接時從輸入流讀取數據的超時時間(毫秒)

比如：

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

如果設置為-1，則表示不超時。

原文鏈接：https://www.javacodegeeks.com/2020/03/7-jvm-arguments-of-highly-effective-applications.html

總結

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

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