JVM參數設置說明
| 參數名稱 | 含義 | 默認值 | |
| -Xms | 初始堆大小 | 物理內存的1/64(<1GB) | 默認(MinHeapFreeRatio參數可以調整)空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制. |
| -Xmx | 最大堆大小 | 物理內存的1/4(<1GB) | 默認(MaxHeapFreeRatio參數可以調整)空餘堆內存大於70%時，JVM會減少堆直到 -Xms的最小限制 |
| -Xmn | 年輕代大小(1.4or lator) | 注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 增大年輕代後,將會減小年老代大小.此值對系統性能影響較大,Sun官方推薦配置爲整個堆的3/8 |
|
| -XX:NewSize | 設置年輕代大小(for 1.3/1.4) | ||
| -XX:MaxNewSize | 年輕代最大值(for 1.3/1.4) | ||
| -XX:PermSize | 設置持久代(perm gen)初始值 | 物理內存的1/64 | |
| -XX:MaxPermSize | 設置持久代最大值 | 物理內存的1/4 | |
| -Xss | 每個線程的堆棧大小 | JDK5.0以後每個線程堆棧大小爲1M,以前每個線程堆棧大小爲256K.更具應用的線程所需內存大小進行 調整.在相同物理內存下,減小這個值能生成更多的線程.但是操作系統對一個進程內的線程數還是有限制的,不能無限生成,經驗值在3000~5000左右 一般小的應用， 如果棧不是很深， 應該是128k夠用的 大的應用建議使用256k。這個選項對性能影響比較大，需要嚴格的測試。（校長） 和threadstacksize選項解釋很類似,官方文檔似乎沒有解釋,在論壇中有這樣一句話:"” -Xss is translated in a VM flag named ThreadStackSize” 一般設置這個值就可以了。 |
|
| -XX:ThreadStackSize | Thread 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區)與年老代的比值(除去持久代) | -XX:NewRatio=4表示年輕代與年老代所佔比值爲1:4,年輕代佔整個堆棧的1/5 Xms=Xmx並且設置了Xmn的情況下，該參數不需要進行設置。 |
|
| -XX:SurvivorRatio | Eden區與Survivor區的大小比值 | 設置爲8,則兩個Survivor區與一個Eden區的比值爲2:8,一個Survivor區佔整個年輕代的1/10 | |
| -XX:LargePageSizeInBytes | 內存頁的大小不可設置過大， 會影響Perm的大小 | =128m | |
| -XX:+UseFastAccessorMethods | 原始類型的快速優化 | ||
| -XX:+DisableExplicitGC | 關閉System.gc() | 這個參數需要嚴格的測試 | |
| -XX:MaxTenuringThreshold | 垃圾最大年齡 | 如果設置爲0的話,則年輕代對象不經過Survivor區,直接進入年老代. 對於年老代比較多的應用,可以提高效率.如果將此值設置爲一個較大值,則年輕代對象會在Survivor區進行多次複製,這樣可以增加對象再年輕代的存活 時間,增加在年輕代即被回收的概率 該參數只有在串行GC時纔有效. |
|
| -XX:+AggressiveOpts | 加快編譯 | ||
| -XX:+UseBiasedLocking | 鎖機制的性能改善 | ||
| -Xnoclassgc | 禁用垃圾回收 | ||
| -XX:SoftRefLRUPolicyMSPerMB | 每兆堆空閒空間中SoftReference的存活時間 | 1s | softly 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 | 單位字節 新生代採用Parallel Scavenge GC時無效 另一種直接在舊生代分配的情況是大的數組對象,且數組中無外部引用對象. |
| -XX:TLABWasteTargetPercent | TLAB佔eden區的百分比 | 1% | |
| -XX:+CollectGen0First | FullGC時是否先YGC | false |
並行收集器相關參數
| -XX:+UseParallelGC | Full GC採用parallel MSC (此項待驗證) |
選擇垃圾收集器爲並行收集器.此配置僅對年輕代有效.即上述配置下,年輕代使用併發收集,而年老代仍舊使用串行收集.(此項待驗證) |
|
| -XX:+UseParNewGC | 設置年輕代爲並行收集 | 可與CMS收集同時使用 JDK5.0以上,JVM會根據系統配置自行設置,所以無需再設置此值 |
|
| -XX:ParallelGCThreads | 並行收集器的線程數 | 此值最好配置與處理器數目相等 同樣適用於CMS | |
| -XX:+UseParallelOldGC | 年老代垃圾收集方式爲並行收集(Parallel Compacting) | 這個是JAVA 6出現的參數選項 | |
| -XX:MaxGCPauseMillis | 每次年輕代垃圾回收的最長時間(最大暫停時間) | 如果無法滿足此時間,JVM會自動調整年輕代大小,以滿足此值. | |
| -XX:+UseAdaptiveSizePolicy | 自動選擇年輕代區大小和相應的Survivor區比例 | 設置此選項後,並行收集器會自動選擇年輕代區大小和相應的Survivor區比例,以達到目標系統規定的最低相應時間或者收集頻率等,此值建議使用並行收集器時,一直打開. | |
| -XX:GCTimeRatio | 設置垃圾回收時間佔程序運行時間的百分比 | 公式爲1/(1+n) | |
| -XX:+ScavengeBeforeFullGC | Full GC前調用YGC | true | Do young generation GC prior to a full GC. (Introduced in 1.4.1.) |
JVM CMS參數設置
| -XX:+UseConcMarkSweepGC | 使用CMS內存收集 | 測試中配置這個以後,-XX:NewRatio=4的配置失效了,原因不明.所以,此時年輕代大小最好用-Xmn設置.??? | |
| -XX:+AggressiveHeap | 試圖是使用大量的物理內存 長時間大內存使用的優化，能檢查計算資源（內存， 處理器數量） 至少需要256MB內存 大量的CPU／內存， （在1.4.1在4CPU的機器上已經顯示有提升） |
||
| -XX:CMSFullGCsBeforeCompaction | 多少次後進行內存壓縮 | 由於併發收集器不對內存空間進行壓縮,整理,所以運行一段時間以後會產生"碎片",使得運行效率降低.此值設置運行多少次GC以後對內存空間進行壓縮,整理. | |
| -XX:+CMSParallelRemarkEnabled | 降低標記停頓 | ||
| -XX+UseCMSCompactAtFullCollection | 在FULL GC的時候， 對年老代的壓縮 | CMS是不會移動內存的， 因此， 這個非常容易產生碎片， 導致內存不夠用， 因此， 內存的壓縮這個時候就會被啓用。 增加這個參數是個好習慣。 可能會影響性能,但是可以消除碎片 |
|
| -XX:+UseCMSInitiatingOccupancyOnly | 使用手動定義初始化定義開始CMS收集 | 禁止hostspot自行觸發CMS GC | |
| -XX:CMSInitiatingOccupancyFraction=70 | 使用cms作爲垃圾回收 使用70％後開始CMS收集 |
92 | 爲了保證不出現promotion failed(見下面介紹)錯誤,該值的設置需要滿足以下公式CMSInitiatingOccupancyFraction計算公式 |
| -XX:CMSInitiatingPermOccupancyFraction | 設置Perm Gen使用到達多少比率時觸發 | 92 | |
| -XX:+CMSIncrementalMode | 設置爲增量模式 | 用於單CPU情況 | |
| -XX:+CMSClassUnloadingEnabled |
JVM輔助信息參數設置
| -XX:+PrintGC |
輸出形式: [GC 118250K->113543K(130112K), 0.0094143 secs] |
||
| -XX:+PrintGCDetails |
輸出形式:[GC [DefNew: 8614K->781K(9088K), 0.0123035 secs] 118250K->113543K(130112K), 0.0124633 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 | 打印每次垃圾回收前,程序未中斷的執行時間.可與上面混合使用 | 輸出形式:Application time: 0.5291524 seconds | |
| -XX:+PrintHeapAtGC | 打印GC前後的詳細堆棧信息 | ||
| -Xloggc:filename | 把相關日誌信息記錄到文件以便分析. 與上面幾個配合使用 |
||
|
-XX:+PrintClassHistogram |
garbage collects before printing the histogram. | ||
| -XX:+PrintTLAB | 查看TLAB空間的使用情況 | ||
| XX:+PrintTenuringDistribution | 查看每次minor GC後新的存活週期的閾值 |
Desired survivor size 1048576 bytes, new threshold 7 (max 15) |
JVM GC垃圾回收器參數設置
JVM給出了3種選擇：串行收集器、並行收集器、併發收集器。串行收集器只適用於小數據量的情況，所以生產環境的選擇主要是並行收集器和併發收集器。
默認情況下JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在啓動時加入相應參數。JDK5.0以後，JVM會根據當前系統配置進行智能判斷。
串行收集器
-XX:+UseSerialGC：設置串行收集器。
並行收集器（吞吐量優先）
-XX:+UseParallelGC：設置爲並行收集器。此配置僅對年輕代有效。即年輕代使用並行收集，而年老代仍使用串行收集。
-XX:ParallelGCThreads=20：配置並行收集器的線程數，即：同時有多少個線程一起進行垃圾回收。此值建議配置與CPU數目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式爲並行收集。JDK6.0開始支持對年老代並行收集。
-XX:MaxGCPauseMillis=100：設置每次年輕代垃圾回收的最長時間（單位毫秒）。如果無法滿足此時間，JVM會自動調整年輕代大小，以滿足此時間。
-XX:+UseAdaptiveSizePolicy：設置此選項後，並行收集器會自動調整年輕代Eden區大小和Survivor區大小的比例，以達成目標系統規定的最低響應時間或者收集頻率等指標。此參數建議在使用並行收集器時，一直打開。
併發收集器（響應時間優先）
-XX:+UseConcMarkSweepGC：即CMS收集，設置年老代爲併發收集。CMS收集是JDK1.4後期版本開始引入的新GC算法。它的主要適合場景是對響應時間的重要性需求大於對吞吐量的需求，能夠承受垃圾回收線程和應用線程共享CPU資源，並且應用中存在比較多的長生命週期對象。CMS收集的目標是儘量減少應用的暫停時間，減少Full GC發生的機率，利用和應用程序線程併發的垃圾回收線程來標記清除年老代內存。
-XX:+UseParNewGC：設置年輕代爲併發收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，所以無需再設置此參數。
-XX:CMSFullGCsBeforeCompaction=0：由於併發收集器不對內存空間進行壓縮和整理，所以運行一段時間並行收集以後會產生內存碎片，內存使用效率降低。此參數設置運行0次Full GC後對內存空間進行壓縮和整理，即每次Full GC後立刻開始壓縮和整理內存。
-XX:+UseCMSCompactAtFullCollection：打開內存空間的壓縮和整理，在Full GC後執行。可能會影響性能，但可以消除內存碎片。
-XX:+CMSIncrementalMode：設置爲增量收集模式。一般適用於單CPU情況。
-XX:CMSInitiatingOccupancyFraction=70：表示年老代內存空間使用到70%時就開始執行CMS收集，以確保年老代有足夠的空間接納來自年輕代的對象，避免Full GC的發生。
其它垃圾回收參數
-XX:+ScavengeBeforeFullGC：年輕代GC優於Full GC執行。
-XX:-DisableExplicitGC：不響應 System.gc() 代碼。
-XX:+UseThreadPriorities：啓用本地線程優先級API。即使 java.lang.Thread.setPriority() 生效，不啓用則無效。
-XX:SoftRefLRUPolicyMSPerMB=0：軟引用對象在最後一次被訪問後能存活0毫秒（JVM默認爲1000毫秒）。
-XX:TargetSurvivorRatio=90：允許90%的Survivor區被佔用（JVM默認爲50%）。提高對於Survivor區的使用率。
JVM參數疑問解答
-Xmn，-XX:NewSize/-XX:MaxNewSize，-XX:NewRatio 3組參數都可以影響年輕代的大小，混合使用的情況下，優先級是什麼？
如下：
高優先級：-XX:NewSize/-XX:MaxNewSize
中優先級：-Xmn（默認等效 -Xmn=-XX:NewSize=-XX:MaxNewSize=?）
低優先級：-XX:NewRatio
推薦使用-Xmn參數，原因是這個參數簡潔，相當於一次設定 NewSize/MaxNewSIze，而且兩者相等，適用於生產環境。-Xmn 配合 -Xms/-Xmx，即可將堆內存佈局完成。
-Xmn參數是在JDK 1.4 開始支持。
JVM參數設置優化例子
1. 承受海量訪問的動態Web應用
服務器配置：8 CPU, 8G MEM, JDK 1.6.X
參數方案：
-server -Xmx3550m -Xms3550m -Xmn1256m -Xss128k -XX:SurvivorRatio=6 -XX:MaxPermSize=256m -XX:ParallelGCThreads=8 -XX:MaxTenuringThreshold=0 -XX:+UseConcMarkSweepGC
調優說明：
-Xmx 與 -Xms 相同以避免JVM反覆重新申請內存。-Xmx 的大小約等於系統內存大小的一半，即充分利用系統資源，又給予系統安全運行的空間。
-Xmn1256m 設置年輕代大小爲1256MB。此值對系統性能影響較大，Sun官方推薦配置年輕代大小爲整個堆的3/8。
-Xss128k 設置較小的線程棧以支持創建更多的線程，支持海量訪問，並提升系統性能。
-XX:SurvivorRatio=6 設置年輕代中Eden區與Survivor區的比值。系統默認是8，根據經驗設置爲6，則2個Survivor區與1個Eden區的比值爲2:6，一個Survivor區佔整個年輕代的1/8。
-XX:ParallelGCThreads=8 配置並行收集器的線程數，即同時8個線程一起進行垃圾回收。此值一般配置爲與CPU數目相等。
-XX:MaxTenuringThreshold=0 設置垃圾最大年齡（在年輕代的存活次數）。如果設置爲0的話，則年輕代對象不經過Survivor區直接進入年老代。對於年老代比較多的應用，可以提高效率；如果將此值設置爲一個較大值，則年輕代對象會在Survivor區進行多次複製，這樣可以增加對象再年輕代的存活時間，增加在年輕代即被回收的概率。根據被海量訪問的動態Web應用之特點，其內存要麼被緩存起來以減少直接訪問DB，要麼被快速回收以支持高併發海量請求，因此其內存對象在年輕代存活多次意義不大，可以直接進入年老代，根據實際應用效果，在這裏設置此值爲0。
-XX:+UseConcMarkSweepGC 設置年老代爲併發收集。CMS（ConcMarkSweepGC）收集的目標是儘量減少應用的暫停時間，減少Full GC發生的機率，利用和應用程序線程併發的垃圾回收線程來標記清除年老代內存，適用於應用中存在比較多的長生命週期對象的情況。
2. 內部集成構建服務器案例
高性能數據處理的工具應用
服務器配置：1 CPU, 4G MEM, JDK 1.6.X
參數方案：
-server -XX:PermSize=196m -XX:MaxPermSize=196m -Xmn320m -Xms768m -Xmx1024m
調優說明：
-XX:PermSize=196m -XX:MaxPermSize=196m 根據集成構建的特點，大規模的系統編譯可能需要加載大量的Java類到內存中，所以預先分配好大量的持久代內存是高效和必要的。
-Xmn320m 遵循年輕代大小爲整個堆的3/8原則。
-Xms768m -Xmx1024m 根據系統大致能夠承受的堆內存大小設置即可。