詳細參數說明
| 參數名稱 | 含義 | 默認值 | |
| -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”. 一般設置128k或者256k這個值就可以了。 |
|
| -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.) |
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 |
輔助信息
| -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) |
關於 -Djava.awt.headless=true
對於一個Java服務器來說經常要處理一些圖形元素，例如地圖的創建或者圖 形和圖表等。這些API基本上總是需要運行一個X-server以便能使用AWT（Abstract Window Toolkit，抽象窗口工具集）。然而，運行一個不必要的X-server並不是一種好的網絡管理方式。
這個解決方案依賴於你的Java版本。如果你運行在JDK1.4上，那麼你將有機會運行headless服務器。
-Djava.awt.headless=true
對於JDK1.3及更低的版本，有個來自eTeks的PJA工具包（Pure Java AWT Toolkit，純Java AWT工具集）可以使用。它是一個在配置上與Sun的1.4版非常相似的headlessJava服務器，這種配置方式包含一組-D屬性標誌。否則會報以下異常
Can’t connect to X11 window server using ‘:0.0′ as the value of the DISPLAY variable
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------
1.與串行回收器相關的參數
- -XX:+UseSerialGC:在新生代和老年代使用串行收集器
- -XX:SurvivorRatio:設置eden區大小和survivor區大小的比例
- -XX:PretenureSizeThreshold:設置大對象直接進入老年代的閾值。當對象的大小超過這個值時，將直接在老年代分配。
- -XX:MaxTenuringThreshold:設置對象進入老年代的年齡的最大值。每一次Minor GC後，對象年齡就加1。任何大於這個年齡的對象，一定會進入老年代。
2.與並行GC相關的參數
- -XX:+UseParNewGC:在新生代使用並行收集器
- -XX:+UseParallelOldGC:老年代使用並行回收收集器
- -XX:ParallelGCThreads:設置用於垃圾回收的線程數。通常情況下可以和CPU數量相等，但在CPU數量較多的情況下，設置相對較小的數值也是合理的。
- -XX:MaxGCPauseMillis:設置最大垃圾收集停頓時間。他的值是一個大於0的整數。收集器在工作時，會調整Java堆大小或者其他參數，儘可能把停頓時間控制在MaxGCPauseMillis以內。
- -XX:GCTimeRatio:設置吞吐量大小。它是0-100的整數。假設GCTimeRatio的值爲n，那麼系統將花費不超過1/(1+n)的時間用於垃圾收集。
- -XX:+UseAdaptiveSizePolicy:打開自適應GC策略。在這種模式下，新生代的大小、eden和survivor的比例、晉升老年代的對象年齡等參數會被自動調整，已達到在堆大小、吞吐量和停頓時間之間的平衡點。
3.與CMS回收期相關的參數
- -XX:+UseConcMarkSweepGC:新生代使用並行收集器，老年代使用CMS+串行收集器
- -XX:ParallelCMSThreads:設定CMS的線程數量
- -XX:CMSInitiatingOccupancyFraction:設置CMS收集器在老年代空間被使用多少後觸發，默認爲68%
- -XX:+UseCMSCompactAtFullCollection:設置CMS收集器完成垃圾收集後是否要進行一次內存碎片的整理
- -XX:CMSFullGCsBeforeCompaction:設定進行多少次CMS垃圾回收後，進行一次內存壓縮
- -XX:+CMSClassUnloadingEnabled:允許對類元數據區進行回收
- -XX:CMSInitiatingPermOccupancyFraction:當永久區佔用率達到這一百分比時，啓動CMS回收(前提是-XX:+CMSClassUnloadingEnabled激活了)
- -XX:UseCMSInitiatingOccupancyOnlyn:表示只在到達閾值的時候才進行CMS回收
- -XX:+CMSIncrementalMode:使用增量模式，比較適合單CPU。增量模式在JDK 8中標記爲廢棄，並將在JDK 9中徹底移除。
4.與G1回收期相關的參數
- -XX:+UseG1GC:使用G1回收器
- -XX:MaxGCPauseMillis:設置最大垃圾收集停頓時間
- -XX:GCPauseIntervalMillis:設置停頓間隔時間
5.TLAB相關
- -XX:+UseTLAB:開啓TLAB分配
- -XX:+PrintTLAB:打印TLAB相關分配信息
- -XX:TLABSize:設置TLAB大小
- -XX:+ResizeTLAB:自動調整TLAB大小
6.其他參數
- -XX:+DisableExplicitGC:禁用顯式GC
- -XX:+ExplicitGCInvokesConcurrent:使用併發方式處理顯式GC