jvm常用參數配置有哪些呢

本篇文章為大家展示了jvm常用參數配置有哪些呢，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。

使用-XX：+UnlockExperimentalVMOptions  -XX：+UseJVMCICompiler參數來啟用Graal編譯器。

打印初始化參數：

java -XX:+PrintFlagsInitial

java -ea TestAssert 用來設置jvm是否啟動斷言機制（從JDK 1.4開始支持），缺省時jvm關閉斷言機制。

-XX:ReservedCodeCacheSize=240m  JIT編譯代碼緩存大小

-XX:SoftRefLRUPolicyMSPerMB=50  默認1000ms .  軟引用存活時間。超過后，在下次垃圾回收時回收。

clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB

clock記錄是上一次GC的時間戳，timestamp則是最近一次讀取soft-reference引用對象。他們的差【clock - timestamp】表示了soft-reference有多久沒用了，越大表示越久沒用。如果軟引用上次被get()的時間離最近一次GC的時間不會太久遠的話就可以不被當前GC回收。解釋： 我們知道軟引用，實在空間不足的情況下才會被回收，當然這個只是一個比較簡單的解釋。實際上軟引用的回收機制復雜得多，需要SoftRefLRUPolicyMSPerMB的意思。

-XX:+HeapDumpOnOutOfMemoryError   堆異常生成文件 -XX:HeapDumpPath=/export/home/tomcat/logs/..

-XX:-OmitStackTraceInFastThrow  是否打印堆棧 ，默認開啟。 大量拋出同樣的異常的后，后面的異常輸出將不打印堆棧。

JVM只對幾個特定類型異常開啟了Fast Throw優化，這些異常包括：NullPointerException，ArithmeticException，ArrayIndexOutOfBoundsException，ArrayStoreException，ClassCastException。

-XX:CICompilerCount=2  最大并行編譯數

-XX：+/-UseTLAB  啟用本地線程內存緩沖區

使用的64位 JVM會默認使用選項 +UseCompressedOops 開啟指針壓縮，將指針壓縮至32位。

JVM默認延時加載偏向鎖。這個延時的時間大概為4s左右，具體時間因機器而異。當然我們也可以設置JVM參數 -XX:BiasedLockingStartupDelay=0 來取消延時加載偏向鎖。

·-XX：MaxMetaspaceSize：設置元空間最大值，默認是-1，即不限制，或者說只受限于本地內存大小。

-XX：MetaspaceSize：指定元空間的初始空間大小，以字節為單位，達到該值就會觸發垃圾收集進行類型卸載，同時收集器會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過-XX：MaxMetaspaceSize（如果設置了的話）的情況下，適當提高該值。

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空間剩余容量的百分比，可減少因為元空間不足導致的垃圾收集的頻率。類似的還有

-XX：MaxMetaspaceFreeRatio，用于控制最大的元空間剩余容量的百分比。

Heap（堆）內存大小設置

-Xms512m    -Xmx1g

New Generation（新生代）內存大小設置

-Xmn256m    =>  -XX:NewSize=256m    -XX:MaxNewSize=256m

設置JVM的新生代內存大小（－Xmn 是將NewSize與MaxNewSize設為一致。256m）.

XX：+HeapDumpOnOutOfMemoryError  可以讓虛擬機在內存溢出異常出現之后自動生成堆轉儲快照文件

設置新生代（包括Eden和兩個Survivor區）與老年代的比值（除去持久代）。設置為3，則新生代與老年代所占比值為1：3，新生代占整個堆棧的1/4

-XX:NewRatio=3

設置為8,則兩個Survivor區與一個Eden區的比值為2:8,一個Survivor區占整個新生代的1/10

-XX:SurvivorRatio=8

Eden內存大小設置：新生代減去2*Survivor的內存大小就是Eden的大小。

Stack(棧)內存大小設置

-Xss1m    每個線程都會產生一個棧。在相同物理內存下，減小這個值能生成更多的線程。如果這個值太小會影響方法調用的深度。

方法區內存分配（JDK8以前的版本使用，JDK8以后沒有持久代了，使用的MetaSpace）

-XX: PermSize=128m 設置持久代初始內存大小128M

-XX:MaxPermSize=512m 設置持久代最大內存大小512M

元空間（Metaspace）(JDK8)  默認20M

-XX:MetaspaceSize=128m -XX:MaxMetaspaceSize=512m（JDK8）

JDK8的持久代幾乎可用完機器的所有內存，同樣設一個128M的初始值，512M的最大值保護一下。

·-XX：MaxMetaspaceSize：設置元空間最大值，默認是-1，即不限制，或者說只受限于本地內存大小。

·-XX：MetaspaceSize：指定元空間的初始空間大小，以字節為單位，達到該值就會觸發垃圾收集進行類型卸載，同時收集器會對該值進行調整：如果釋放了大量的空間，就適當降低該值；如果釋放了很少的空間，那么在不超過-XX：MaxMetaspaceSize（如果設置了的話）的情況下，適當提高該值

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空間剩余容量的百分比，可減少因為元空間不足導致的垃圾收集的頻率。

類似的還有-XX：Max-MetaspaceFreeRatio，用于控制最大的元空間剩余容量的百分比。

方法區的垃圾收集主要回收兩部分內容：廢棄的常量和不再使用的類型。回收廢棄常量與回收Java堆中的對象非常類似。舉個常量池中字面量回收的例子，假如一個字符串“java”曾經進入常量池

中，但是當前系統又沒有任何一個字符串對象的值是“java”，換句話說，已經沒有任何字符串對象引用常量池中的“java”常量，且虛擬機中也沒有其他地方引用這個字面量。如果在這時發生內存回收，而且

垃圾收集器判斷確有必要的話，這個“java”常量就將會被系統清理出常量池。常量池中其他類（接口）、方法、字段的符號引用也與此類似。

-Xnoclassgc  表示關閉JVM對方法區類的垃圾回收

Direct ByteBuffer（直接內存）內存大小設置

-XX:MaxDirectMemorySize

設置新生代代對象進入老年代的年齡

-XX:MaxTenuringThreshold=15

單位字節）對象大小大于1024字節的直接在老年代分配對象,-XX：PretenureSizeThreshold參數只對Serial和ParNew兩款新生代收集器有效，HotSpot

的其他新生代收集器，如Parallel Scavenge并不支持這個參數。如果必須使用此參數進行調優，可考慮ParNew加CMS的收集器組合。

-XX:PretenureSizeThreshold=1024

TLAB占eden區的百分比 默認1%

-XX:TLABWasteTargetPercent =1

因此在eclipse.ini中加入參數-XX：+DisableExplicitGC屏蔽掉System.gc()。

垃圾收集

配套策略

CMS作為老年代的收集器，卻無法與JDK 1.4.0中已經存在的新生代收集器Parallel    Scavenge配合工作 。

Serial  + Serial Old  (客戶端常用）  -XX: +UseSerialGC

ParNew + Serial Old  (少用）  -XX: +UseParNewGC    jdk9后不支持

Serial  + CMS  （少用）

ParNew + CMS  (jdk5 常用）+ （并發失敗 Serial Old） 

-XX: +UseConcMarkSweepGC  -XX：+UseCMS-CompactAtFullCollection -XX：CMSFullGCsBefore-Compaction=6

-XX:CMSInitiatingOccupancyFraction=70   CMS垃圾收集器，當老年代達到70%時，觸發CMS垃圾回收。

Parallel Scavenge + Serial Old     -XX:+UseParallelGC

Parallel Scavenge + Paraller Old (jdk6 常用） -XX:+UseParallelOldGC

G1   -XX: +UseG1GC

ZGC使用

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC  XX:+UseNUMA

Epsilon   -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC

Epsilon收集器  不能夠進行垃圾收集為“賣點”的垃圾收集器

ParNew收集器是激活CMS后（使用-XX：+UseConcMarkSweepGC選項）的默認新生代收集器，也可以使用-XX：+/-UseParNewGC選項來強制指定或者禁用它。所以自JDK 9開始，ParNew加CMS收集器的組合就不再是官方推薦的服務端模式下的收集器解決方案了。官方希望它能完全被G1所取代，甚至還取消了ParNew加Serial Old以及Serial加CMS這兩組收集器組合的支持（其實原本也很少人這樣使用），并直接取消了-XX：+UseParNewGC參數，這意味著ParNew和CMS從此只能互相搭配使用，再也沒有其他收集器能夠和它們配合了。

ParNew收集器

-XX：ParallelGCThreads參數來限制垃圾收集的線程數。

Parallel Scavenge收集器

Parallel Scavenge收集器提供了兩個參數用于精確控制吞吐量，分別是控制最大垃圾收集停頓時間的-XX：MaxGCPauseMillis參數以及直接設置吞吐量大小的-XX：GCTimeRatio參數

-XX：MaxGCPauseMillis參數允許的值是一個大于0的毫秒數，收集器將盡力保證內存回收花費的時間不超過用戶設定值。

-XX：GCTimeRatio參數的值則應當是一個大于0小于100的整數，也就是垃圾收集時間占總時間的比率。譬如把此參數設置為19，那允許的最大垃圾收集時間就占總時間的5%（即1/(1+19)），默認值為99，即允許最大1%（即1/(1+99)）的垃圾收集時間。

-XX：+UseAdaptiveSizePolicy。這是一個開關參數，當這個參數被激活之后，就不需要人工指定新生代的大小（-Xmn）、Eden與Survivor區的比例（-XX：SurvivorRatio）、晉升老年代對象大小（-XX：PretenureSizeThreshold）等細節參數了，虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或者最大的吞吐量。這種調節方式稱為垃圾收集的自適應的調節策略（GC Ergonomics）

CMS收集器提供了一個-XX：+UseCMS-CompactAtFullCollection開關參數（默認是開啟的，此參數從JDK 9開始廢棄） fullGC時開啟內存整理。

-XX：CMSFullGCsBefore-Compaction（此參數從JDK 9開始廢棄），這個參數的作用是要求CMS收集器在執行過若干次（數量由參數值決定）不整理空間的Full GC之后，下一次進入Full GC前會先進行碎片整理（默認值為0，表示每次進入Full GC時都進行碎片整理）。

調高參數-XX：CMSInitiatingOccu-pancyFraction的值來提高CMS的觸發百分比 ， 達到該百分比，進行垃圾收集。到了JDK 6時，CMS收集器的啟動閾值就已經默認提升至92%。但這又會更容易面臨另一種風險：要是CMS運行期間預留的內存無法滿足程序分配新對象的需要，就會出現一次“并發失敗”（Concurrent Mode Failure），這時候虛擬機將不得不啟動后備預案：凍結用戶線程的執行，臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，但這樣停頓時間就很長了

G1收集

使用參數-XX：MaxGCPauseMillis指定，默認值是200毫秒），優先處理回收價值收益最大的那些Region，設定允許的收集停頓時間

每個Region的大小可以通過參數-XX：G1HeapRegionSize設定，取值范圍為1MB～32MB，且應為2的N次冪。

暫不支持類卸載（JDK 11時不支持，JDK 12的ZGC已經支持）

日志：

-Xlog[:[selector][:[output][:[decorators][:output-options]]]]

命令行中最關鍵的參數是選擇器（Selector），它由標簽（Tag）和日志級別（Level）共同組成，垃圾收集器的標簽名稱為“gc”。

全部支持的gc功能模塊標簽名如下所示

add，age，alloc，annotation，aot，arguments，attach，barrier，biasedlocking，blocks，bot，breakpoint，bytecode

另外，還可以使用修飾器（Decorator）來要求每行日志輸出都附加上額外的內容，支持附加在日志行上的信息包括：

·time：當前日期和時間。

·uptime：虛擬機啟動到現在經過的時間，以秒為單位。

·timemillis：當前時間的毫秒數，相當于System.currentTimeMillis()的輸出。

·uptimemillis：虛擬機啟動到現在經過的毫秒數。

·timenanos：當前時間的納秒數，相當于System.nanoTime()的輸出。

·uptimenanos：虛擬機啟動到現在經過的納秒數。

·pid：進程ID。

·tid：線程ID。

·level：日志級別。

如果不配置，默認的是：

-Xlog:all=warning:stdout:uptime,level,tags

-XX:+UseG1GC -Xms20M -Xmx20M -Xmn10M -Xlog:all=info:stdout:uptime,level,tags,time

-Xlog[:[what][:[output][:[decorators][:output-options[,...]]]]]

-Xlog:gc*=info，表示包含 gc 標簽的所有日志，info 級別的都會輸出，就是上面說的 gc 相關的所有標簽。

-XX:+UseG1GC -Xms20M -Xmx20M -Xmn10M -Xlog:gc*=info:stdout:time,uptime,tags

output

包含三種輸出：

* stdout： 標準輸出

* stderr： 標準錯誤輸出

* file=filename 輸出到文件

對于輸出到文件可以配置output-options：filecount=50,filesize=100M這個表示保留50個文件，每個文件100M

java -Xlog:gc GCTest

查看GC基本信息，在JDK 9之前使用-XX：+PrintGC，JDK 9后使用-Xlog：gc：

查看GC詳細信息，在JDK 9之前使用-XX：+PrintGCDetails，在JDK 9之后使用-X-log：gc*，用通配符*將GC標簽下所有細分過程都打印出來，如果把日志級別調整到Debug或者Trace

查看GC前后的堆、方法區可用容量變化，在JDK 9之前使用-XX：+PrintHeapAtGC，JDK 9之后使用-Xlog：gc+heap=debug：

查看GC過程中用戶線程并發時間以及停頓的時間，在JDK 9之前使用-XX：+Print-GCApplicationConcurrentTime以及-XX：+PrintGCApplicationStoppedTime，JDK 9之后使用-Xlog：safepoint    java -Xlog:safepoint GCTest

查看收集器Ergonomics機制（自動設置堆空間各分代區域大小、收集目標等內容，從Parallel收集器開始支持）自動調節的相關信息。在JDK 9之前使用-XX：+PrintAdaptive-SizePolicy，JDK 9之后使用-Xlog：gc+ergo*=trace：    java -Xlog:gc+ergo*=trace GCTest

查看熬過收集后剩余對象的年齡分布信息，在JDK 9前使用-XX：+PrintTenuring-Distribution，JDK 9之后使用-Xlog：gc+age=trace：    java -Xlog:gc+age=trace GCTest

-verbose:gc 開啟GC日志

-XX:+PrintGCDetails -Xloggc:./gc.log -XX:+PrintGCDateStamps 將GC日志詳情輸入到gc.log中

但是加入參數-XX：+PrintGCApplicationStoppedTime-XX：+PrintGCDate-Stamps-Xloggc：gclog.log后，從收集器日志文件中確認了停頓確實是由垃圾收集導致的，大部分收集時間都控制在100毫秒以內，但偶爾就出現一次接近1分鐘的長時間收集過程。

在Java的GUI程序中要避免這種現象，可以加入參數“-Dsun.awt.keepWorkingSetOnMinimize=true”來解決。這個參數在許多AWT的程序上都有應用，例如JDK（曾經）自帶的VisualVM，啟動配置文件中就有這個參數，

所以先加入參數-XX：+PrintSafepointStatistics和-XX：PrintSafepointStatisticsCount=1去查看安全點日志，

添加-XX：+SafepointTimeout和-XX：SafepointTimeoutDelay=2000兩個參數，讓虛擬機在等到線程進入安全點的時間超過2000毫秒時就認定為超時，這樣就會輸出導致問題的線程名稱，

我們已經知道安全點是以“是否具有讓程序長時間執行的特征”為原則進行選定的，所以方法調用、循環跳轉、異常跳轉這些位置都可能會設置有安全點，但是HotSpot虛擬機為了避免安全點過多帶來過重的負擔，對循環還有一項優化措施，認為循環次數較少的話，執行時間應該也不會太長，所以使用int類型或范圍更小

的數據類型作為索引值的循環默認是不會被放置安全點的。這種循環被稱為可數循環（Counted Loop），相對應地，使用long或者范圍更大的數據類型作為索引值的循環就被稱為不可數循環（Uncounted Loop），將會被放置安全點。通常情況下這個優化措施是可行的，但循環執行的時間不單單是由其次數決定，如果循環體單次執行就特別慢，那即使是可數循環也可能會耗費很多的時間。

上述內容就是jvm常用參數配置有哪些呢，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。