JVM參數(shù)設置說明

參數(shù)名稱含義默認值

-Xms初始堆大小物理內(nèi)存的1/64(<1GB)默認(MinHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存小于40%時，JVM就會增大堆直到-Xmx的最大限制.

-Xmx最大堆大小物理內(nèi)存的1/4(<1GB)默認(MaxHeapFreeRatio參數(shù)可以調(diào)整)空余堆內(nèi)存大于70%時，JVM會減少堆直到 -Xms的最小限制

-Xmn年輕代大小(1.4or lator)注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。

整個堆大小=年輕代大小 + 年老代大小 + 持久代大小.

增大年輕代后,將會減小年老代大小.此值對系統(tǒng)性能影響較大,Sun官方推薦配置為整個堆的3/8

-XX:NewSize設置年輕代大小(for 1.3/1.4)

-XX:MaxNewSize年輕代最大值(for 1.3/1.4)

-XX:PermSize設置持久代(perm gen)初始值物理內(nèi)存的1/64

-XX:MaxPermSize設置持久代最大值物理內(nèi)存的1/4

-Xss每個線程的堆棧大小JDK5.0以后每個線程堆棧大小為1M,以前每個線程堆棧大小為256K.更具應用的線程所需內(nèi)存大小進行 調(diào)整.在相同物理內(nèi)存下,減小這個值能生成更多的線程.但是操作系統(tǒng)對一個進程內(nèi)的線程數(shù)還是有限制的,不能無限生成,經(jīng)驗值在3000~5000左右

一般小的應用， 如果棧不是很深， 應該是128k夠用的 大的應用建議使用256k。這個選項對性能影響比較大，需要嚴格的測試。（校長）

和threadstacksize選項解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"”

-Xss is translated in a VM flag named ThreadStackSize”

一般設置這個值就可以了。

-XX:ThreadStackSizeThread Stack Size(0 means use default stack size) [Sparc: 512; Solaris x86: 320 (was 256 prior in 5.0 and earlier); Sparc 64 bit: 1024; Linux amd64: 1024 (was 0 in 5.0 and earlier); all others 0.]

-XX:NewRatio年輕代(包括Eden和兩個Survivor區(qū))與年老代的比值(除去持久代)-XX:NewRatio=4表示年輕代與年老代所占比值為1:4,年輕代占整個堆棧的1/5

Xms=Xmx并且設置了Xmn的情況下，該參數(shù)不需要進行設置。

-XX:SurvivorRatioEden區(qū)與Survivor區(qū)的大小比值設置為8,則兩個Survivor區(qū)與一個Eden區(qū)的比值為2:8,一個Survivor區(qū)占整個年輕代的1/10

-XX:LargePageSizeInBytes內(nèi)存頁的大小不可設置過大， 會影響Perm的大小#ERROR!

-XX:+UseFastAccessorMethods原始類型的快速優(yōu)化

-XX:+DisableExplicitGC關閉System.gc()這個參數(shù)需要嚴格的測試

-XX:MaxTenuringThreshold垃圾最大年齡如果設置為0的話,則年輕代對象不經(jīng)過Survivor區(qū),直接進入年老代. 對于年老代比較多的應用,可以提高效率.如果將此值設置為一個較大值,則年輕代對象會在Survivor區(qū)進行多次復制,這樣可以增加對象再年輕代的存活 時間,增加在年輕代即被回收的概率

該參數(shù)只有在串行GC時才有效.

-XX:+AggressiveOpts加快編譯

-XX:+UseBiasedLocking鎖機制的性能改善

-Xnoclassgc禁用垃圾回收

-XX:SoftRefLRUPolicyMSPerMB每兆堆空閑空間中SoftReference的存活時間1ssoftly reachable objects will remain alive for some amount of time after the last time they were referenced. The default value is one second of lifetime per free megabyte in the heap

-XX:PretenureSizeThreshold對象超過多大是直接在舊生代分配0單位字節(jié) 新生代采用Parallel Scavenge GC時無效

另一種直接在舊生代分配的情況是大的數(shù)組對象,且數(shù)組中無外部引用對象.

-XX:TLABWasteTargetPercentTLAB占eden區(qū)的百分比1%

-XX:+CollectGen0FirstFullGC時是否先YGCfalse

并行收集器相關參數(shù)

-XX:+UseParallelGCFull GC采用parallel MSC選擇垃圾收集器為并行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用并發(fā)收集,而年老代仍舊使用串行收集.(此項待驗證)

(此項待驗證)

-XX:+UseParNewGC設置年輕代為并行收集可與CMS收集同時使用

JDK5.0以上,JVM會根據(jù)系統(tǒng)配置自行設置,所以無需再設置此值

-XX:ParallelGCThreads并行收集器的線程數(shù)此值最好配置與處理器數(shù)目相等 同樣適用于CMS

-XX:+UseParallelOldGC年老代垃圾收集方式為并行收集(Parallel Compacting)這個是JAVA 6出現(xiàn)的參數(shù)選項

-XX:MaxGCPauseMillis每次年輕代垃圾回收的最長時間(最大暫停時間)如果無法滿足此時間,JVM會自動調(diào)整年輕代大小,以滿足此值.

-XX:+UseAdaptiveSizePolicy自動選擇年輕代區(qū)大小和相應的Survivor區(qū)比例設置此選項后,并行收集器會自動選擇年輕代區(qū)大小和相應的Survivor區(qū)比例,以達到目標系統(tǒng)規(guī)定的最低相應時間或者收集頻率等,此值建議使用并行收集器時,一直打開.

-XX:GCTimeRatio設置垃圾回收時間占程序運行時間的百分比公式為1/(1+n)

-XX:+ScavengeBeforeFullGCFull GC前調(diào)用YGCtrueDo young generation GC prior to a full GC. (Introduced in 1.4.1.)

JVM CMS參數(shù)設置

-XX:+UseConcMarkSweepGC使用CMS內(nèi)存收集測試中配置這個以后,-XX:NewRatio=4的配置失效了,原因不明.所以,此時年輕代大小最好用-Xmn設置.???

-XX:+AggressiveHeap試圖是使用大量的物理內(nèi)存

長時間大內(nèi)存使用的優(yōu)化，能檢查計算資源（內(nèi)存， 處理器數(shù)量）

至少需要256MB內(nèi)存

大量的CPU／內(nèi)存， （在1.4.1在4CPU的機器上已經(jīng)顯示有提升）

-XX:CMSFullGCsBeforeCompaction多少次后進行內(nèi)存壓縮由于并發(fā)收集器不對內(nèi)存空間進行壓縮,整理,所以運行一段時間以后會產(chǎn)生"碎片",使得運行效率降低.此值設置運行多少次GC以后對內(nèi)存空間進行壓縮,整理.

-XX:+CMSParallelRemarkEnabled降低標記停頓

-XX+UseCMSCompactAtFullCollection在FULL GC的時候， 對年老代的壓縮CMS是不會移動內(nèi)存的， 因此， 這個非常容易產(chǎn)生碎片， 導致內(nèi)存不夠用， 因此， 內(nèi)存的壓縮這個時候就會被啟用。 增加這個參數(shù)是個好習慣。

可能會影響性能,但是可以消除碎片

-XX:+UseCMSInitiatingOccupancyOnly使用手動定義初始化定義開始CMS收集禁止hostspot自行觸發(fā)CMS GC

-XX:CMSInitiatingOccupancyFraction=70使用cms作為垃圾回收92為了保證不出現(xiàn)promotion failed(見下面介紹)錯誤,該值的設置需要滿足以下公式CMSInitiatingOccupancyFraction計算公式

使用70％后開始CMS收集

-XX:CMSInitiatingPermOccupancyFraction設置Perm Gen使用到達多少比率時觸發(fā)92

-XX:+CMSIncrementalMode設置為增量模式用于單CPU情況

-XX:+CMSClassUnloadingEnabled

JVM輔助信息參數(shù)設置

-XX:+PrintGC輸出形式:

[GC 118250K->113543K(130112K), 0.0094143 secs]

[Full GC 121376K->10414K(130112K), 0.0650971 secs]

-XX:+PrintGCDetails輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs]

[GC [DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured: 112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K), 0.0436268 secs]

-XX:+PrintGCTimeStamps

-XX:+PrintGC:PrintGCTimeStamps可與-XX:+PrintGC -XX:+PrintGCDetails混合使用

輸出形式:11.851: [GC 98328K->93620K(130112K), 0.0082960 secs]

-XX:+PrintGCApplicationStoppedTime打印垃圾回收期間程序暫停的時間.可與上面混合使用輸出形式:Total time for which application threads were stopped: 0.0468229 seconds

-XX:+PrintGCApplicationConcurrentTime打印每次垃圾回收前,程序未中斷的執(zhí)行時間.可與上面混合使用輸出形式:Application time: 0.5291524 seconds

-XX:+PrintHeapAtGC打印GC前后的詳細堆棧信息

-Xloggc:filename把相關日志信息記錄到文件以便分析.

與上面幾個配合使用

-XX:+PrintClassHistogramgarbage collects before printing the histogram.

-XX:+PrintTLAB查看TLAB空間的使用情況

XX:+PrintTenuringDistribution查看每次minor GC后新的存活周期的閾值Desired survivor size 1048576 bytes, new threshold 7 (max 15)

new threshold 7即標識新的存活周期的閾值為7。

JVM GC垃圾回收器參數(shù)設置

JVM給出了3種選擇：串行收集器、并行收集器、并發(fā)收集器。串行收集器只適用于小數(shù)據(jù)量的情況，所以生產(chǎn)環(huán)境的選擇主要是并行收集器和并發(fā)收集器。

默認情況下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啟動時加入相應參數(shù)。JDK5.0以后，JVM會根據(jù)當前系統(tǒng)配置進行智能判斷。

串行收集器

-XX:+UseSerialGC：設置串行收集器。

并行收集器（吞吐量優(yōu)先）

-XX:+UseParallelGC：設置為并行收集器。此配置僅對年輕代有效。即年輕代使用并行收集，而年老代仍使用串行收集。

-XX:ParallelGCThreads=20：配置并行收集器的線程數(shù)，即：同時有多少個線程一起進行垃圾回收。此值建議配置與CPU數(shù)目相等。

-XX:+UseParallelOldGC：配置年老代垃圾收集方式為并行收集。JDK6.0開始支持對年老代并行收集。

-XX:MaxGCPauseMillis=100：設置每次年輕代垃圾回收的最長時間（單位毫秒）。如果無法滿足此時間，JVM會自動調(diào)整年輕代大小，以滿足此時間。

-XX:+UseAdaptiveSizePolicy：設置此選項后，并行收集器會自動調(diào)整年輕代Eden區(qū)大小和Survivor區(qū)大小的比例，以達成目標系統(tǒng)規(guī)定的最低響應時間或者收集頻率等指標。此參數(shù)建議在使用并行收集器時，一直打開。

并發(fā)收集器（響應時間優(yōu)先）

-XX:+UseConcMarkSweepGC：即CMS收集，設置年老代為并發(fā)收集。CMS收集是JDK1.4后期版本開始引入的新GC算法。它的主要適合場景是對響應時間的重要性需求大于對吞吐量的需求，能夠承受垃圾回收線程和應用線程共享CPU資源，并且應用中存在比較多的長生命周期對象。CMS收集的目標是盡量減少應用的暫停時間，減少Full GC發(fā)生的幾率，利用和應用程序線程并發(fā)的垃圾回收線程來標記清除年老代內(nèi)存。

-XX:+UseParNewGC：設置年輕代為并發(fā)收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據(jù)系統(tǒng)配置自行設置，所以無需再設置此參數(shù)。

-XX:CMSFullGCsBeforeCompaction=0：由于并發(fā)收集器不對內(nèi)存空間進行壓縮和整理，所以運行一段時間并行收集以后會產(chǎn)生內(nèi)存碎片，內(nèi)存使用效率降低。此參數(shù)設置運行0次Full GC后對內(nèi)存空間進行壓縮和整理，即每次Full GC后立刻開始壓縮和整理內(nèi)存。

-XX:+UseCMSCompactAtFullCollection：打開內(nèi)存空間的壓縮和整理，在Full GC后執(zhí)行?？赡軙绊懶阅?，但可以消除內(nèi)存碎片。

-XX:+CMSIncrementalMode：設置為增量收集模式。一般適用于單CPU情況。

-XX:CMSInitiatingOccupancyFraction=70：表示年老代內(nèi)存空間使用到70%時就開始執(zhí)行CMS收集，以確保年老代有足夠的空間接納來自年輕代的對象，避免Full GC的發(fā)生。

其它垃圾回收參數(shù)

-XX:+ScavengeBeforeFullGC：年輕代GC優(yōu)于Full GC執(zhí)行。

-XX:-DisableExplicitGC：不響應 System.gc() 代碼。

-XX:+UseThreadPriorities：啟用本地線程優(yōu)先級API。即使 java.lang.Thread.setPriority() 生效，不啟用則無效。

-XX:SoftRefLRUPolicyMSPerMB=0：軟引用對象在最后一次被訪問后能存活0毫秒（JVM默認為1000毫秒）。

-XX:TargetSurvivorRatio=90：允許90%的Survivor區(qū)被占用（JVM默認為50%）。提高對于Survivor區(qū)的使用率。

JVM參數(shù)疑問解答

-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3組參數(shù)都可以影響年輕代的大小，混合使用的情況下，優(yōu)先級是什么？

如下：

高優(yōu)先級：-XX:NewSize/-XX:MaxNewSize?

中優(yōu)先級：-Xmn（默認等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）?

低優(yōu)先級：-XX:NewRatio?

推薦使用-Xmn參數(shù)，原因是這個參數(shù)簡潔，相當于一次設定 NewSize/MaxNewSIze，而且兩者相等，適用于生產(chǎn)環(huán)境。-Xmn 配合 -Xms/-Xmx，即可將堆內(nèi)存布局完成。

-Xmn參數(shù)是在JDK 1.4 開始支持。

JVM參數(shù)設置優(yōu)化例子

1. 承受海量訪問的動態(tài)Web應用

服務器配置：8 CPU, 8G MEM, JDK 1.6.X

參數(shù)方案：

-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC

調(diào)優(yōu)說明：

-Xmx 與 -Xms 相同以避免JVM反復重新申請內(nèi)存。-Xmx 的大小約等于系統(tǒng)內(nèi)存大小的一半，即充分利用系統(tǒng)資源，又給予系統(tǒng)安全運行的空間。

-Xmn1256m 設置年輕代大小為1256MB。此值對系統(tǒng)性能影響較大，Sun官方推薦配置年輕代大小為整個堆的3/8。

-Xss128k 設置較小的線程棧以支持創(chuàng)建更多的線程，支持海量訪問，并提升系統(tǒng)性能。

-XX:SurvivorRatio=6 設置年輕代中Eden區(qū)與Survivor區(qū)的比值。系統(tǒng)默認是8，根據(jù)經(jīng)驗設置為6，則2個Survivor區(qū)與1個Eden區(qū)的比值為2:6，一個Survivor區(qū)占整個年輕代的1/8。

-XX:ParallelGCThreads=8 配置并行收集器的線程數(shù)，即同時8個線程一起進行垃圾回收。此值一般配置為與CPU數(shù)目相等。

-XX:MaxTenuringThreshold=0 設置垃圾最大年齡（在年輕代的存活次數(shù)）。如果設置為0的話，則年輕代對象不經(jīng)過Survivor區(qū)直接進入年老代。對于年老代比較多的應用，可以提高效率；如果將此值設置為一個較大值，則年輕代對象會在Survivor區(qū)進行多次復制，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概率。根據(jù)被海量訪問的動態(tài)Web應用之特點，其內(nèi)存要么被緩存起來以減少直接訪問DB，要么被快速回收以支持高并發(fā)海量請求，因此其內(nèi)存對象在年輕代存活多次意義不大，可以直接進入年老代，根據(jù)實際應用效果，在這里設置此值為0。

-XX:+UseConcMarkSweepGC 設置年老代為并發(fā)收集。CMS（ConcMarkSweepGC）收集的目標是盡量減少應用的暫停時間，減少Full GC發(fā)生的幾率，利用和應用程序線程并發(fā)的垃圾回收線程來標記清除年老代內(nèi)存，適用于應用中存在比較多的長生命周期對象的情況。

2. 內(nèi)部集成構(gòu)建服務器案例

高性能數(shù)據(jù)處理的工具應用

服務器配置：1 CPU, 4G MEM, JDK 1.6.X

參數(shù)方案：

-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m

調(diào)優(yōu)說明：

-XX:PermSize=196m -XX:MaxPermSize=196m 根據(jù)集成構(gòu)建的特點，大規(guī)模的系統(tǒng)編譯可能需要加載大量的Java類到內(nèi)存中，所以預先分配好大量的持久代內(nèi)存是高效和必要的。

-Xmn320m 遵循年輕代大小為整個堆的3/8原則。

-Xms768m -Xmx1024m 根據(jù)系統(tǒng)大致能夠承受的堆內(nèi)存大小設置即可。