JVM 參數設置

 

 

無論是YGC仍是Full GC,GC過程當中都會對致使程序運行中中斷,正確的選擇不一樣的GC策略,調整JVM、GC的參數，能夠極大的減小因爲GC工做，而致使的程序運行中斷方面的問題，進而適當的提升Java程序的工做效率。可是調整GC是以個極爲複雜的過程，因爲各個程序具有不一樣的特色，如：web和GUI程序就有很大區別（Web能夠適當的停頓，但GUI停頓是客戶沒法接受的），並且因爲跑在各個機器上的配置不一樣（主要cup個數，內存不一樣），因此使用的GC種類也會不一樣(如何選擇見GC種類及如何選擇)。本文將注重介紹JVM、GC的一些重要參數的設置來提升系統的性能。

       JVM內存組成及GC相關內容請見以前的文章:JVM內存組成 GC策略&內存申請。

JVM參數的含義 實例見實例分析

參數名稱	含義	默認值
-Xms	初始堆大小	物理內存的1/64(<1GB)	默認(MinHeapFreeRatio參數能夠調整)空餘堆內存小於40%時，JVM就會增大堆直到-Xmx的最大限制.
-Xmx	最大堆大小	物理內存的1/4(<1GB)	默認(MaxHeapFreeRatio參數能夠調整)空餘堆內存大於70%時，JVM會減小堆直到 -Xms的最小限制
-Xmn	年輕代大小(1.4or lator)		注意： 整個堆大小=年輕代大小 + 年老代大小  增大年輕代後,將會減少年老代大小.此值對系統性能影響較大,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

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%的空餘）。

經驗&&規則

1. 年輕代大小選擇
   • 響應時間優先的應用:儘量設大,直到接近系統的最低響應時間限制(根據實際狀況選擇).在此種狀況下,年輕代收集發生的頻率也是最小的.同時,減小到達年老代的對象.
   • 吞吐量優先的應用:儘量的設置大,可能到達Gbit的程度.由於對響應時間沒有要求,垃圾收集能夠並行進行,通常適合8CPU以上的應用.
   • 避免設置太小.當新生代設置太小時會致使:1.YGC次數更加頻繁 2.可能致使YGC對象直接進入舊生代,若是此時舊生代滿了,會觸發FGC.
2. 年老代大小選擇
   1. 響應時間優先的應用:年老代使用併發收集器,因此其大小須要當心設置,通常要考慮併發會話率和會話持續時間等一些參數.若是堆設置小了,能夠會形成內存碎 片,高回收頻率以及應用暫停而使用傳統的標記清除方式;若是堆大了,則須要較長的收集時間.最優化的方案,通常須要參考如下數據得到:
      併發垃圾收集信息、持久代併發收集次數、傳統GC信息、花在年輕代和年老代回收上的時間比例。
   2. 吞吐量優先的應用:通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代.緣由是,這樣能夠儘量回收掉大部分短時間對象,減小中期的對象,而年老代盡存放長期存活對象.
3. 較小堆引發的碎片問題
   由於年老代的併發收集器使用標記,清除算法,因此不會對堆進行壓縮.當收集器回收時,他會把相鄰的空間進行合併,這樣能夠分配給較大的對象.可是,當堆空間較小時,運行一段時間之後,就會出現"碎片",若是併發收集器找不到足夠的空間,那麼併發收集器將會中止,而後使用傳統的標記,清除方式進行回收.若是出現"碎片",可能須要進行以下配置:
   -XX:+UseCMSCompactAtFullCollection:使用併發收集器時,開啓對年老代的壓縮.
   -XX:CMSFullGCsBeforeCompaction=0:上面配置開啓的狀況下,這裏設置多少次Full GC後,對年老代進行壓縮
4. 用64位操做系統，Linux下64位的jdk比32位jdk要慢一些，可是吃得內存更多，吞吐量更大
5. XMX和XMS設置同樣大，MaxPermSize和MinPermSize設置同樣大，這樣能夠減輕伸縮堆大小帶來的壓力
6. 使用CMS的好處是用盡可能少的新生代，經驗值是128M－256M， 而後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間很是的短，2G的內存， 大約20－80ms的應用程序停頓時間
7. 系統停頓的時候多是GC的問題也多是程序的問題，多用jmap和jstack查看，或者killall -3 java，而後查看java控制檯日誌，能看出不少問題。(相關工具的使用方法將在後面的blog中介紹)
8. 仔細瞭解本身的應用，若是用了緩存，那麼年老代應該大一些，緩存的HashMap不該該無限制長，建議採用LRU算法的Map作緩存，LRUMap的最大長度也要根據實際狀況設定。
9. 採用併發回收時，年輕代小一點，年老代要大，由於年老大用的是併發回收，即便時間長點也不會影響其餘程序繼續運行，網站不會停頓
10. JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio  -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，須要根據PV old區實際數據 YGC次數等多方面來衡量。爲了不promotion faild可能會致使xmn設置偏小，也意味着YGC的次數會增多，處理併發訪問的能力降低等問題。每一個參數的調整都須要通過詳細的性能測試，才能找到特定應用的最佳配置。

     java.lang.StackOverflowError:（不多）
     java.lang.OutOfMemoryError：heap space(比較常見)
     java.lang.OutOfMemoryError: PermGen space (常常出現)

 java.lang.OutOfMemoryError: PermGen space 這個異常比較常見，是說ＪＶＭ裏的Perm內存區的異常溢出，因爲JVM在默認的狀況下，Perm默認爲64M，而不少程序須要大量的Perm區內存，尤爲使用到像spring等框架的時候，因爲須要使用到動態生成類，而這些類不能被GC自動釋放，因此致使OutOfMemoryError: PermGen space異常。解決方法很簡單，增大JVM的 -XX:MaxPermSize 啓動參數，就能夠解決這個問題

 java.lang.OutOfMemoryError：heap space或 其它OutOfMemoryError，這個異常實際上跟上面的異常是一個異常，但解決方法不一樣，因此分開來寫。上面那個異常是由於JVM的perm區內存區分少了引發的（JVM的內存區分爲 young,old,perm三種）。而這個異常是由於JVM堆內存或者說整體分少了。解決方法是更改 -Xms -Xmx 啓動參數，一般是擴大1倍。xms是管理啓動時最小內存量的，xmx是管裏JVM最大的內存量的

StackOverflowError

在單線程操做中，不管是棧深度無限增長，仍是棧幀(每一個方法調用執行時都會在棧中建立一個棧幀，用來存儲局部變量，操做數棧，動態鏈表，方法出口等信息)佔的空間太大，都出現的是StackOverflowError