JVM參數設定
1.基本參數
| 參數名稱 | 含義 | 預設值 | |
| -Xms | 初始堆大小 | 記憶體的1/64 | 預設(MinHeapFreeRatio參數可以調整)空餘堆記憶體小于40%時，JVM就會增大堆直到-Xmx的最大限制. |
| -Xmx | 最大堆大小 | 記憶體的1/4 | 預設(MaxHeapFreeRatio參數可以調整)空餘堆記憶體大于70%時，JVM會減少堆直到 -Xms的最小限制 |
| -Xmn | 年輕代大小 | 注意：此處的大小是（eden+ 2 survivor space).與jmap -heap中顯示的New gen是不同的。 整個堆大小=年輕代大小 + 年老代大小 + 持久代大小. 增大年輕代後,将會減小年老代大小.此值對系統性能影響較大,Sun官方推薦配置為整個堆的3/8 | |
| -XX:NewSize | 設定年輕代大小 | ||
| -XX:MaxNewSize | 年輕代最大值 | ||
| -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:+ExplicitGCInvokesConcurrent | 關閉System.gc() | disabled | Enables invoking of concurrent GC by using the System.gc() request. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option. |
| -XX:+ExplicitGCInvokesConcurrentAndUnloadsClasses | 關閉System.gc() | disabled | Enables invoking of concurrent GC by using the System.gc() request and unloading of classes during the concurrent GC cycle. This option is disabled by default and can be enabled only together with the -XX:+UseConcMarkSweepGC option. |
| -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 | 對象超過多大是直接在舊生代配置設定 | 機關位元組 新生代采用Parallel Scavenge GC時無效 另一種直接在舊生代配置設定的情況是大的數組對象,且數組中無外部引用對象. | |
| -XX:TLABWasteTargetPercent | TLAB占eden區的百分比 | 1% | |
| -XX:+CollectGen0First | FullGC時是否先YGC | false |
Jdk7版本的主要參數
| 參數名稱 | 含義 | 預設值 |
| -XX:PermSize | 設定持久代 | Jdk7版本及以前版本 |
| -XX:MaxPermSize | 設定最大持久代 | Jdk7版本及以前版本 |
Jdk8版本的重要特有參數
| 參數名稱 | 含義 | 預設值 |
| -XX:MetaspaceSize | 元空間大小 | Jdk8版本 |
| -XX:MaxMetaspaceSize | 最大元空間 | Jdk8版本 |
2.并行收集器相關參數
| 參數名稱 | 含義 | 預設值 | |
| -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.) |
3.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 |
4.輔助資訊
| 參數名稱 | 含義 | 預設值 |
| -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 | 列印每次垃圾回收前,程式未中斷的執行時間.可與上面混合使用 | 輸出形式: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) new threshold 7即辨別新的存活周期的門檻值為7。 |
5.啟動參數例子
jdk8啟動 -server -Xms1366m -Xmx2g -Xmn768m -Xss256k -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=5 -XX:GCTimeRatio=19 -Xnoclassgc -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:-CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintHeapAtGC -Xloggc:/data/logs/api-gc.log
6.GC性能方面的考慮
GC性能方面的考慮
對于GC的性能主要有2個方面的名額：吞吐量throughput（工作時間不算gc的時間占總的時間比）和暫停pause（gc發生時app對外顯示的無法響應）。
1.Total Heap
預設情況下，vm會增加/減少heap大小以維持free space在整個vm中占的比例，這個比例由MinHeapFreeRatio和MaxHeapFreeRatio指定。
一般而言，server端的app會有以下規則：
- 對vm配置設定盡可能多的memory；
- 将Xms和Xmx設為一樣的值。如果虛拟機啟動時設定使用的記憶體比較小，這個時候又需要初始化很多對象，虛拟機就必須重複地增加記憶體。
- 處理器核數增加，記憶體也跟着增大。
2.The Young Generation
另外一個對于app流暢性運作影響的因素是young generation的大小。young generation越大，minor collection越少；但是在固定heap size情況下，更大的young generation就意味着小的tenured generation，就意味着更多的major collection(major collection會引發minor collection)。
NewRatio反映的是young和tenured generation的大小比例。NewSize和MaxNewSize反映的是young generation大小的下限和上限，将這兩個值設為一樣就固定了young generation的大小（同Xms和Xmx設為一樣）。
如果希望，SurvivorRatio也可以優化survivor的大小，不過這對于性能的影響不是很大。SurvivorRatio是eden和survior大小比例。
一般而言，server端的app會有以下規則：
- 首先決定能配置設定給vm的最大的heap size，然後設定最佳的young generation的大小；
- 如果heap size固定後，增加young generation的大小意味着減小tenured generation大小。讓tenured generation在任何時候夠大，能夠容納所有live的data（留10%-20%的空餘）。
經驗&&規則
- 年老代大小選擇
-
響應時間優先的應用:年老代使用并發收集器,是以其大小需要小心設定,一般要考慮并發會話率和會話持續時間等一些參數.如果堆設定小了,可以會造成記憶體碎 片,高回收頻率以及應用暫停而使用傳統的标記清除方式;
如果堆大了,則需要較長的收集時間.最優化的方案,一般需要參考以下資料獲得:
并發垃圾收集資訊、持久代并發收集次數、傳統GC資訊、花在年輕代和年老代回收上的時間比例。
- 吞吐量優先的應用:一般吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.原因是,這樣可以盡可能回收掉大部分短期對象,減少中期的對象,而年老代盡存放長期存活對象.
-
-
較小堆引起的碎片問題
因為年老代的并發收集器使用标記,清除算法,是以不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合并,這樣可以配置設定給較大的對象.但是,當堆空間較小時,運作一段時間以後,就會出現"碎片",如果并發收集器找不到足夠的空間,那麼并發收集器将會停止,然後使用傳統的标記,清除方式進行回收. 如果出現"碎片",可能需要進行如下配置:
-XX:+UseCMSCompactAtFullCollection:使用并發收集器時,開啟對年老代的壓縮.
-XX:CMSFullGCsBeforeCompaction=0:上面配置開啟的情況下,這裡設定多少次Full GC後,對年老代進行壓縮
- 用64位作業系統，Linux下64位的jdk比32位jdk要慢一些，但是吃得記憶體更多，吞吐量更大
- XMX和XMS設定一樣大，MaxPermSize和MinPermSize設定一樣大，這樣可以減輕伸縮堆大小帶來的壓力
- 使用CMS的好處是用盡量少的新生代，經驗值是128M－256M， 然後老生代利用CMS并行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間非常的短，2G的記憶體， 大約20－80ms的應用程式停頓時間
- 系統停頓的時候可能是GC的問題也可能是程式的問題，多用jmap和jstack檢視，或者kill all -3 java，然後檢視java控制台日志，能看出很多問題。(相關工具的使用方法将在後面的blog中介紹)
- 仔細了解自己的應用，如果用了緩存，那麼年老代應該大一些，緩存的HashMap不應該無限制長，建議采用LRU算法的Map做緩存，LRUMap的最大長度也要根據實際情況設定。
- 采用并發回收時，年輕代小一點，年老代要大，因為年老大用的是并發回收，即使時間長點也不會影響其他程式繼續運作，網站不會停頓
- JVM參數的設定(特别是 –Xmx –Xms –Xmn -XX:SurvivorRatio -XX:MaxTenuringThreshold等參數的設定沒有一個固定的公式，需要根據PV old區實際資料 YGC次數等多方面來衡量。為了避免promotion faild可能會導緻xmn設定偏小，也意味着YGC的次數會增多，處理并發通路的能力下降等問題。每個參數的調整都需要經過詳細的性能測試，才能找到特定應用的最佳配置。
promotion failed:
垃圾回收時promotion failed是個很頭痛的問題，一般可能是兩種原因産生，
- 第一個原因是救助空間不夠，救助空間裡的對象還不應該被移動到年老代，但年輕代又有很多對象需要放入救助空間；
- 第二個原因是年老代沒有足夠的空間接納來自年輕代的對象；這兩種情況都會轉向Full GC，網站停頓時間較長。
解決方方案一：
第一個原因我的最終解決辦法是去掉救助空間，設定-XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0即可，第二個原因我的解決辦法是設定CMSInitiatingOccupancyFraction為某個值（假設70），這樣年老代空間到70%時就開始執行CMS，年老代有足夠的空間接納來自年輕代的對象。
解決方案一的改進方案：
又有改進了，上面方法不太好，因為沒有用到救助空間，是以年老代容易滿，CMS執行會比較頻繁。我改善了一下，還是用救助空間，但是把救助空間加大，這樣也不會有promotion failed。具體操作上，32位Linux和64位Linux好像不一樣，64位系統似乎隻要配置MaxTenuringThreshold參數，CMS還是有暫停。為了解決暫停問題和promotion failed問題，最後我設定-XX:SurvivorRatio=1 ，并把MaxTenuringThreshold去掉，這樣即沒有暫停又不會有promotoin failed，而且更重要的是，年老代和永久代上升非常慢（因為好多對象到不了年老代就被回收了），是以CMS執行頻率非常低，好幾個小時才執行一次，這樣，伺服器都不用重新開機了。
-Xmx4000M -Xms4000M -Xmn600M -XX:PermSize=500M -XX:MaxPermSize=500M -Xss256K -XX:+DisableExplicitGC -XX:SurvivorRatio=1 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:LargePageSizeInBytes=128M -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=80 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:+PrintClassHistogram -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC -Xloggc:log/gc.log
CMSInitiatingOccupancyFraction值與Xmn的關系公式
上面介紹了promontion faild産生的原因是EDEN空間不足的情況下将EDEN與From survivor中的存活對象存入To survivor區時,To survivor區的空間不足，再次晉升到old gen區，而old gen區記憶體也不夠的情況下産生了promontion faild進而導緻full gc.那可以推斷出：eden+from survivor < old gen區剩餘記憶體時，不會出現promontion faild的情況，即：
(Xmx-Xmn)*(1-CMSInitiatingOccupancyFraction/100)>=(Xmn-Xmn/(SurvivorRatior+2)) 進而推斷出：
CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100
例如：
當xmx=128 xmn=36 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-36)-(36-36/(1+2)))/(128-36)*100 =73.913
當xmx=128 xmn=24 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((128.0-24)-(24-24/(1+2)))/(128-24)*100=84.615…
當xmx=3000 xmn=600 SurvivorRatior=1時 CMSInitiatingOccupancyFraction<=((3000.0-600)-(600-600/(1+2)))/(3000-600)*100=83.33
CMSInitiatingOccupancyFraction低于70% 需要調整xmn或SurvivorRatior值。
網上一童鞋 推斷出的公式是：:(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn 這個公式個人認為不是很嚴謹，在記憶體小的時候會影響xmn的計算。
Java8 HotSpot VM Options
Java8 VM Turning
Frequently Asked Questions About the Java HotSpot VM
Java SE HotSpot at a Glance
Java7 HotSpot VM Options
![java｜ this關鍵字[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)