jvm性能參數與調優

本文中的參數並齊全，看了http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html的相關文章寫得很好，能夠看一看

1.jvm堆內存簡介

gc主要工做在堆上，下面簡單介紹一下堆的構成

堆分爲兩部分 新生代區與老年區和持久區，新生代區存放新生成的對象，老年區存放生存過幾輪gc的對象和較大的對象。持久區存放一些類信息，jvm內部對象等。

新生代區由Eden區和兩個Survival區構成。

新建的對象會盡可能放在Eden區裏面，同時只能有一個Survival區工做，另外一個Survival應該是空的。在執行gc時，將不須要被回收的對象放進空的那個Survival區中（若是放不下，則會放到老年區中）。而後將原來兩個區進行清理，實現內存的釋放。而在Survival區中的對象年齡加1，當年齡足夠時（由MaxTenuringThreshold控制），將會移動到老年區中。

年輕區內執行的gc是複製移動。老年區執行的則是標記刪除或者採用併發收集器，當老年區產生較多碎片，沒法劃出一塊須要的空間時，或者進行了指定次數的gc後（也能夠配置，在下文中介紹）則會進行傳統的標記、刪除gc。

每當咱們啓動一個java程序時，都會啓動一個jvm虛擬機，若是咱們在啓動時不進行配置，jvm就會採用默認參數。下面咱們來說一下都有哪些參數能夠配置。

2.jvm參數

堆設置

-Xms:初始堆大小

-Xmx:最大堆大小

-Xmn/-XX:NewSize=n:設置年輕代大小

-Xss:設置每一個線程的堆棧大小

-XX:NewRatio=n:設置年輕代和年老代的比值。如:爲3，表示年輕代與年老代比值爲1：3，年輕代佔整個年輕代年老代和的1/4

-XX:SurvivorRatio=n:年輕代中Eden區與兩個Survivor區的比值。注意Survivor區有兩個。如：3，表示Eden：Survivor=3：2，一個Survivor區佔整個年輕代的1/5

-XX:MaxPermSize=n:設置持久代大小

-XX:MaxTenuringThreshold=0：設置垃圾最大年齡。

3.gc類別

JVM給了三種選擇：串行收集器、並行收集器、併發收集器，可是串行收集器只適用於小數據量的狀況，因此這裏的選擇主要針對並行收集器和併發收集器。默認狀況下，JDK5.0之前都是使用串行收集器，若是想使用其餘收集器須要在啓動時加入相應參數。JDK5.0之後，JVM會根據當前系統配置進行判斷。

3.1吞吐量優先的並行收集器
如上文所述，並行收集器主要以到達必定的吞吐量爲目標，適用於科學技術和後臺處理等。
典型配置：

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20
-XX:+UseParallelGC：選擇垃圾收集器爲並行收集器。此配置僅對年輕代有效。即上述配置下，年輕代使用併發收集，而年老代仍舊使用串行收集。
-XX:ParallelGCThreads=20：配置並行收集器的線程數，即：同時多少個線程一塊兒進行垃圾回收。此值最好配置與處理器數目相等。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC
-XX:+UseParallelOldGC：配置年老代垃圾收集方式爲並行收集。JDK6.0支持對年老代並行收集。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=100:設置每次年輕代垃圾回收的最長時間，若是沒法知足此時間，JVM會自動調全年輕代大小，以知足此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100-XX:+UseAdaptiveSizePolicy
-XX:+UseAdaptiveSizePolicy：設置此選項後，並行收集器會自動選擇年輕代區大小和相應的Survivor區比例，以達到目標系統規定的最低相應時間或者收集頻率等，此值建議使用並行收集器時，一直打開。

 

並行收集器設置

-XX:ParallelGCThreads=n:設置並行收集器收集時使用的CPU數。並行收集線程數。

-XX:MaxGCPauseMillis=n:設置並行收集最大暫停時間

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

3.2響應時間優先的併發收集器
如上文所述，併發收集器主要是保證系統的響應時間，減小垃圾收集時的停頓時間。適用於應用服務器、電信領域等。
典型配置：

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+UseConcMarkSweepGC：設置年老代爲併發收集。測試中配置這個之後，-XX:NewRatio=4的配置失效了，緣由不明。因此，此時年輕代大小最好用-Xmn設置。
-XX:+UseParNewGC:設置年輕代爲並行收集。可與CMS收集同時使用。JDK5.0以上，JVM會根據系統配置自行設置，因此無需再設置此值。

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseConcMarkSweepGC -XX:CMSFullGCsBeforeCompaction=5 -XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction：因爲併發收集器不對內存空間進行壓縮、整理，因此運行一段時間之後會產生「碎片」，使得運行效率下降。此值設置運行多少次GC之後對內存空間進行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection：打開對年老代的壓縮。可能會影響性能，可是能夠消除碎片

併發收集器設置

-XX:+UseConcMarkSweepGC   使用CMS內存收集
-XX:+AggressiveHeap 特別說明下：(我感受對於作java cache應用有幫助)

• 試圖是使用大量的物理內存
• 長時間大內存使用的優化，能檢查計算資源（內存， 處理器數量）
• 至少須要256MB內存
• 大量的CPU／內存， （在1.4.1在4CPU的機器上已經顯示有提高）

-XX:+UseParNewGC 容許多線程收集新生代
-XX:+CMSParallelRemarkEnabled  下降標記停頓

-XX+UseCMSCompactAtFullCollection  在FULL GC的時候， 壓縮內存， CMS是不會移動內存的， 所以， 這個很是容易產生碎片， 致使內存不夠用， 所以， 內存的壓縮這個時候就會被啓用。 增長這個參數是個好習慣。 

-XX:+CMSIncrementalMode:設置爲增量模式。適用於單CPU狀況。

-XX:ParallelGCThreads=n:設置併發收集器年輕代收集方式爲並行收集時，使用的CPU數。並行收集線程數。

使用CMS的前提條件是你有比較的長生命對象， 好比有200M以上的OLD堆佔用。 那麼這個威力很是猛， 能夠極大的提升的FGC的收集能力。 若是你的OLD佔用很是的少， 別用了， 絕對下降你性能， 由於CMS收集有2個STOP WORLD的行爲。 OLD少的清狀況， 根據個人測試， 使用並行收集參數會比較好。

4.輔助

可讓jvm打印回收的日誌來幫助調試

-XX:+PrintGC

-XX:+PrintGCDetails

-XX:+PrintGCTimeStamps

-Xloggc:filename

5.優化

年輕代大小選擇

響應時間優先的應用：儘量設大，直到接近系統的最低響應時間限制（根據實際狀況選擇）。在此種狀況下，年輕代收集發生的頻率也是最小的。同時，減小到達年老代的對象。

吞吐量優先的應用：儘量的設置大，可能到達Gbit的程度。由於對響應時間沒有要求，垃圾收集能夠並行進行，通常適合8CPU以上的應用。

5.2年老代大小選擇

響應時間優先的應用：年老代使用併發收集器，因此其大小須要當心設置，通常要考慮併發會話率和會話持續時間等一些參數。若是堆設置小了，能夠會形成內存碎片、高回收頻率以及應用暫停而使用傳統的標記清除方式；若是堆大了，則須要較長的收集時間。最優化的方案，通常須要參考如下數據得到：

併發垃圾收集信息

持久代併發收集次數

傳統GC信息

花在年輕代和年老代回收上的時間比例

 

5.3吞吐量優先的應用：

通常吞吐量優先的應用都有一個很大的年輕代和一個較小的年老代。緣由是，這樣能夠儘量回收掉大部分短時間對象，減小中期的對象，而年老代盡存放長期存活對象。

 

5.4較小堆引發的碎片問題

由於年老代的併發收集器使用標記、清除算法，因此不會對堆進行壓縮。當收集器回收時，他會把相鄰的空間進行合併，這樣能夠分配給較大的對象。可是，當堆空間較小時，運行一段時間之後，就會出現「碎片」，若是併發收集器找不到足夠的空間，那麼併發收集器將會中止，而後使用傳統的標記、清除方式進行回收。若是出現「碎片」，可能須要進行以下配置：

 

-XX:+UseCMSCompactAtFullCollection：使用併發收集器時，開啓對年老代的壓縮。

-XX:CMSFullGCsBeforeCompaction=0：上面配置開啓的狀況下，這裏設置多少次Full GC後，對年老代進行壓縮

5.5XMX和XMS設置同樣大

MaxPermSize和MinPermSize設置同樣大，這樣能夠減輕伸縮堆大小帶來的壓力

5.6使用CMS的好處

用盡可能少的新生代，經驗值是128M－256M， 而後老生代利用CMS並行收集， 這樣能保證系統低延遲的吞吐效率。 實際上cms的收集停頓時間很是的短，2G的內存， 大約20－80ms的應用程序停頓時間

5.7系統停頓的時候多是GC的問題也多是程序的問題，多用jmap和jstack查看，或者killall -3 java，而後查看java控制檯日誌，能看出不少問題。(相關工具的使用方法將在後面的blog中介紹)

5.8仔細瞭解本身的應用，若是用了緩存，那麼年老代應該大一些，緩存的HashMap不該該無限制長，建議採用LRU算法的Map作緩存，LRUMap的最大長度也要根據實際狀況設定。

5.9採用併發回收時，年輕代小一點，年老代要大，由於年老大用的是併發回收，即便時間長點也不會影響其餘程序繼續運行，網站不會停頓

6.0JVM參數的設置(特別是 –Xmx –Xms –Xmn -XX:SurvivorRatio  -XX:MaxTenuringThreshold等參數的設置沒有一個固定的公式，須要根據PV old區實際數據 YGC次數等多方面來衡量。爲了不promotion faild可能會致使xmn設置偏小，也意味着YGC的次數會增多，處理併發訪問的能力降低等問題。每一個參數的調整都須要通過詳細的性能測試，才能找到特定應用的最佳配置。