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

目前創(chuàng)新互聯(lián)公司已為數(shù)千家的企業(yè)提供了網(wǎng)站建設(shè)、域名、雅安服務(wù)器托管、網(wǎng)站托管、服務(wù)器托管、企業(yè)網(wǎng)站設(shè)計(jì)、沁陽網(wǎng)站維護(hù)等服務(wù)，公司將堅(jiān)持客戶導(dǎo)向、應(yīng)用為本的策略，正道將秉承"和諧、參與、激情"的文化，與客戶和合作伙伴齊心協(xié)力一起成長，共同發(fā)展。

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

打印初始化參數(shù)：

java -XX:+PrintFlagsInitial

java -ea TestAssert 用來設(shè)置jvm是否啟動(dòng)斷言機(jī)制（從JDK 1.4開始支持），缺省時(shí)jvm關(guān)閉斷言機(jī)制。

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

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

clock - timestamp <= freespace * SoftRefLRUPolicyMSPerMB

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

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

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

JVM只對(duì)幾個(gè)特定類型異常開啟了Fast Throw優(yōu)化，這些異常包括：NullPointerException，ArithmeticException，ArrayIndexOutOfBoundsException，ArrayStoreException，ClassCastException。

-XX:CICompilerCount=2  最大并行編譯數(shù)

-XX：+/-UseTLAB  啟用本地線程內(nèi)存緩沖區(qū)

使用的64位 JVM會(huì)默認(rèn)使用選項(xiàng) +UseCompressedOops 開啟指針壓縮，將指針壓縮至32位。

JVM默認(rèn)延時(shí)加載偏向鎖。這個(gè)延時(shí)的時(shí)間大概為4s左右，具體時(shí)間因機(jī)器而異。當(dāng)然我們也可以設(shè)置JVM參數(shù) -XX:BiasedLockingStartupDelay=0 來取消延時(shí)加載偏向鎖。

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

-XX：MetaspaceSize：指定元空間的初始空間大小，以字節(jié)為單位，達(dá)到該值就會(huì)觸發(fā)垃圾收集進(jìn)行類型卸載，同時(shí)收集器會(huì)對(duì)該值進(jìn)行調(diào)整：如果釋放了大量的空間，就適當(dāng)降低該值；如果釋放了很少的空間，那么在不超過-XX：MaxMetaspaceSize（如果設(shè)置了的話）的情況下，適當(dāng)提高該值。

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空間剩余容量的百分比，可減少因?yàn)樵臻g不足導(dǎo)致的垃圾收集的頻率。類似的還有

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

Heap（堆）內(nèi)存大小設(shè)置

-Xms512m    -Xmx1g

New Generation（新生代）內(nèi)存大小設(shè)置

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

設(shè)置JVM的新生代內(nèi)存大?。ǎ璛mn 是將NewSize與MaxNewSize設(shè)為一致。256m）.

XX：+HeapDumpOnOutOfMemoryError  可以讓虛擬機(jī)在內(nèi)存溢出異常出現(xiàn)之后自動(dòng)生成堆轉(zhuǎn)儲(chǔ)快照文件

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

-XX:NewRatio=3

設(shè)置為8,則兩個(gè)Survivor區(qū)與一個(gè)Eden區(qū)的比值為2:8,一個(gè)Survivor區(qū)占整個(gè)新生代的1/10

-XX:SurvivorRatio=8

Eden內(nèi)存大小設(shè)置：新生代減去2*Survivor的內(nèi)存大小就是Eden的大小。

Stack(棧)內(nèi)存大小設(shè)置

-Xss1m    每個(gè)線程都會(huì)產(chǎn)生一個(gè)棧。在相同物理內(nèi)存下，減小這個(gè)值能生成更多的線程。如果這個(gè)值太小會(huì)影響方法調(diào)用的深度。

方法區(qū)內(nèi)存分配（JDK8以前的版本使用，JDK8以后沒有持久代了，使用的MetaSpace）

-XX: PermSize=128m 設(shè)置持久代初始內(nèi)存大小128M

-XX:MaxPermSize=512m 設(shè)置持久代最大內(nèi)存大小512M

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

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

JDK8的持久代幾乎可用完機(jī)器的所有內(nèi)存，同樣設(shè)一個(gè)128M的初始值，512M的最大值保護(hù)一下。

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

·-XX：MetaspaceSize：指定元空間的初始空間大小，以字節(jié)為單位，達(dá)到該值就會(huì)觸發(fā)垃圾收集進(jìn)行類型卸載，同時(shí)收集器會(huì)對(duì)該值進(jìn)行調(diào)整：如果釋放了大量的空間，就適當(dāng)降低該值；如果釋放了很少的空間，那么在不超過-XX：MaxMetaspaceSize（如果設(shè)置了的話）的情況下，適當(dāng)提高該值

·-XX：MinMetaspaceFreeRatio：作用是在垃圾收集之后控制最小的元空間剩余容量的百分比，可減少因?yàn)樵臻g不足導(dǎo)致的垃圾收集的頻率。

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

方法區(qū)的垃圾收集主要回收兩部分內(nèi)容：廢棄的常量和不再使用的類型?；厥諒U棄常量與回收J(rèn)ava堆中的對(duì)象非常類似。舉個(gè)常量池中字面量回收的例子，假如一個(gè)字符串“java”曾經(jīng)進(jìn)入常量池

中，但是當(dāng)前系統(tǒng)又沒有任何一個(gè)字符串對(duì)象的值是“java”，換句話說，已經(jīng)沒有任何字符串對(duì)象引用常量池中的“java”常量，且虛擬機(jī)中也沒有其他地方引用這個(gè)字面量。如果在這時(shí)發(fā)生內(nèi)存回收，而且

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

-Xnoclassgc  表示關(guān)閉JVM對(duì)方法區(qū)類的垃圾回收

Direct ByteBuffer（直接內(nèi)存）內(nèi)存大小設(shè)置

-XX:MaxDirectMemorySize

設(shè)置新生代代對(duì)象進(jìn)入老年代的年齡

-XX:MaxTenuringThreshold=15

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

的其他新生代收集器，如Parallel Scavenge并不支持這個(gè)參數(shù)。如果必須使用此參數(shù)進(jìn)行調(diào)優(yōu)，可考慮ParNew加CMS的收集器組合。

-XX:PretenureSizeThreshold=1024

TLAB占eden區(qū)的百分比 默認(rèn)1%

-XX:TLABWasteTargetPercent =1

因此在eclipse.ini中加入?yún)?shù)-XX：+DisableExplicitGC屏蔽掉System.gc()。

垃圾收集

配套策略

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

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

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

Serial  + CMS  （少用）

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

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

-XX:CMSInitiatingOccupancyFraction=70   CMS垃圾收集器，當(dāng)老年代達(dá)到70%時(shí)，觸發(fā)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收集器  不能夠進(jìn)行垃圾收集為“賣點(diǎn)”的垃圾收集器

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

ParNew收集器

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

Parallel Scavenge收集器

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

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

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

-XX：+UseAdaptiveSizePolicy。這是一個(gè)開關(guān)參數(shù)，當(dāng)這個(gè)參數(shù)被激活之后，就不需要人工指定新生代的大?。?Xmn）、Eden與Survivor區(qū)的比例（-XX：SurvivorRatio）、晉升老年代對(duì)象大?。?XX：PretenureSizeThreshold）等細(xì)節(jié)參數(shù)了，虛擬機(jī)會(huì)根據(jù)當(dāng)前系統(tǒng)的運(yùn)行情況收集性能監(jiān)控信息，動(dòng)態(tài)調(diào)整這些參數(shù)以提供最合適的停頓時(shí)間或者最大的吞吐量。這種調(diào)節(jié)方式稱為垃圾收集的自適應(yīng)的調(diào)節(jié)策略（GC Ergonomics）

CMS收集器提供了一個(gè)-XX：+UseCMS-CompactAtFullCollection開關(guān)參數(shù)（默認(rèn)是開啟的，此參數(shù)從JDK 9開始廢棄） fullGC時(shí)開啟內(nèi)存整理。

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

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

G1收集

使用參數(shù)-XX：MaxGCPauseMillis指定，默認(rèn)值是200毫秒），優(yōu)先處理回收價(jià)值收益最大的那些Region，設(shè)定允許的收集停頓時(shí)間

每個(gè)Region的大小可以通過參數(shù)-XX：G1HeapRegionSize設(shè)定，取值范圍為1MB～32MB，且應(yīng)為2的N次冪。

暫不支持類卸載（JDK 11時(shí)不支持，JDK 12的ZGC已經(jīng)支持）

日志：

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

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

全部支持的gc功能模塊標(biāo)簽名如下所示

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

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

·time：當(dāng)前日期和時(shí)間。

·uptime：虛擬機(jī)啟動(dòng)到現(xiàn)在經(jīng)過的時(shí)間，以秒為單位。

·timemillis：當(dāng)前時(shí)間的毫秒數(shù)，相當(dāng)于System.currentTimeMillis()的輸出。

·uptimemillis：虛擬機(jī)啟動(dòng)到現(xiàn)在經(jīng)過的毫秒數(shù)。

·timenanos：當(dāng)前時(shí)間的納秒數(shù)，相當(dāng)于System.nanoTime()的輸出。

·uptimenanos：虛擬機(jī)啟動(dòng)到現(xiàn)在經(jīng)過的納秒數(shù)。

·pid：進(jìn)程ID。

·tid：線程ID。

·level：日志級(jí)別。

如果不配置，默認(rèn)的是：

-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 標(biāo)簽的所有日志，info 級(jí)別的都會(huì)輸出，就是上面說的 gc 相關(guān)的所有標(biāo)簽。

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

output

包含三種輸出：

* stdout： 標(biāo)準(zhǔn)輸出

* stderr： 標(biāo)準(zhǔn)錯(cuò)誤輸出

* file=filename 輸出到文件

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

java -Xlog:gc GCTest

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

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

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

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

查看收集器Ergonomics機(jī)制（自動(dòng)設(shè)置堆空間各分代區(qū)域大小、收集目標(biāo)等內(nèi)容，從Parallel收集器開始支持）自動(dòng)調(diào)節(jié)的相關(guān)信息。在JDK 9之前使用-XX：+PrintAdaptive-SizePolicy，JDK 9之后使用-Xlog：gc+ergo*=trace：    java -Xlog:gc+ergo*=trace GCTest

查看熬過收集后剩余對(duì)象的年齡分布信息，在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中

但是加入?yún)?shù)-XX：+PrintGCApplicationStoppedTime-XX：+PrintGCDate-Stamps-Xloggc：gclog.log后，從收集器日志文件中確認(rèn)了停頓確實(shí)是由垃圾收集導(dǎo)致的，大部分收集時(shí)間都控制在100毫秒以內(nèi)，但偶爾就出現(xiàn)一次接近1分鐘的長時(shí)間收集過程。

在Java的GUI程序中要避免這種現(xiàn)象，可以加入?yún)?shù)“-Dsun.awt.keepWorkingSetOnMinimize=true”來解決。這個(gè)參數(shù)在許多AWT的程序上都有應(yīng)用，例如JDK（曾經(jīng)）自帶的VisualVM，啟動(dòng)配置文件中就有這個(gè)參數(shù)，

所以先加入?yún)?shù)-XX：+PrintSafepointStatistics和-XX：PrintSafepointStatisticsCount=1去查看安全點(diǎn)日志，

添加-XX：+SafepointTimeout和-XX：SafepointTimeoutDelay=2000兩個(gè)參數(shù)，讓虛擬機(jī)在等到線程進(jìn)入安全點(diǎn)的時(shí)間超過2000毫秒時(shí)就認(rèn)定為超時(shí)，這樣就會(huì)輸出導(dǎo)致問題的線程名稱，

我們已經(jīng)知道安全點(diǎn)是以“是否具有讓程序長時(shí)間執(zhí)行的特征”為原則進(jìn)行選定的，所以方法調(diào)用、循環(huán)跳轉(zhuǎn)、異常跳轉(zhuǎn)這些位置都可能會(huì)設(shè)置有安全點(diǎn)，但是HotSpot虛擬機(jī)為了避免安全點(diǎn)過多帶來過重的負(fù)擔(dān)，對(duì)循環(huán)還有一項(xiàng)優(yōu)化措施，認(rèn)為循環(huán)次數(shù)較少的話，執(zhí)行時(shí)間應(yīng)該也不會(huì)太長，所以使用int類型或范圍更小

的數(shù)據(jù)類型作為索引值的循環(huán)默認(rèn)是不會(huì)被放置安全點(diǎn)的。這種循環(huán)被稱為可數(shù)循環(huán)（Counted Loop），相對(duì)應(yīng)地，使用long或者范圍更大的數(shù)據(jù)類型作為索引值的循環(huán)就被稱為不可數(shù)循環(huán)（Uncounted Loop），將會(huì)被放置安全點(diǎn)。通常情況下這個(gè)優(yōu)化措施是可行的，但循環(huán)執(zhí)行的時(shí)間不單單是由其次數(shù)決定，如果循環(huán)體單次執(zhí)行就特別慢，那即使是可數(shù)循環(huán)也可能會(huì)耗費(fèi)很多的時(shí)間。

上述內(nèi)容就是jvm常用參數(shù)配置有哪些呢，你們學(xué)到知識(shí)或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識(shí)儲(chǔ)備，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。