JVM監控與調優

一、JVM內存及參數設置

-Xmn
新生代內存大小的最大值，包括E區和兩個S區的總和，使用方法如：-Xmn65535，-Xmn1024k，-Xmn512m，-Xmn1g (-Xms,-Xmx也是種寫法)
-Xmn只能使用在JDK1.4或之后的版本中，（之前的1.3/1.4版本中，可使用-XX:NewSize設置年輕代大小，用-XX:MaxNewSize設置年輕代最大值）；
如果同時設置了-Xmn和-XX:NewSize，-XX:MaxNewSize，則誰設置在后面，誰就生效；如果同時設置了-XX:NewSize -XX:MaxNewSize與-XX:NewRatio則實際生效的值是：min(MaxNewSize,max(NewSize, heap/(NewRatio+1)))（看考：http://www.open-open.com/home/space.php?uid=71669&do=blog&id=8891）
在開發、測試環境，可以-XX:NewSize 和 -XX:MaxNewSize來設置新生代大小，但在線上生產環境，使用-Xmn一個即可（推薦），或者將-XX:NewSize 和 -XX:MaxNewSize設置為同一個值，這樣能夠防止在每次GC之后都要調整堆的大小（即：抖動，抖動會嚴重影響性能）

 -Xms
初始堆的大小，也是堆大小的最小值，默認值是總共的物理內存/64（且小於1G），默認情況下，當堆中可用內存小於40%(這個值可以用-XX: MinHeapFreeRatio 調整，如-X:MinHeapFreeRatio=30)時，堆內存會開始增加，一直增加到-Xmx的大小；

 -Xmx
堆的最大值，默認值是總共的物理內存/64（且小於1G），如果Xms和Xmx都不設置，則兩者大小會相同，默認情況下，當堆中可用內存大於70%（這個值可以用-XX: MaxHeapFreeRatio 調整，如-X:MaxHeapFreeRatio=60）時，堆內存會開始減少，一直減小到-Xms的大小；
整個堆的大小=年輕代大小+年老代大小，堆的大小不包含持久代大小，如果增大了年輕代，年老代相應就會減小，官方默認的配置為年老代大小/年輕代大小=2/1左右（使用-XX:NewRatio可以設置-XX:NewRatio=5，表示年老代/年輕代=5/1）；
建議在開發測試環境可以用Xms和Xmx分別設置最小值最大值，但是在線上生產環境，Xms和Xmx設置的值必須一樣，原因與年輕代一樣——防止抖動；

 -Xss
這個參數用於設置每個線程的棧內存，默認1M，一般來說是不需要改的。除非代碼不多，可以設置的小點，另外一個相似的參數是-XX:ThreadStackSize，這兩個參數在1.6以前，都是誰設置在后面，誰就生效；1.6版本以后，-Xss設置在后面，則以-Xss為准，-XXThreadStackSize設置在后面，則主線程以-Xss為准，其它線程以-XX:ThreadStackSize為准。

 -Xrs
減少JVM對操作系統信號（OS Signals）的使用（JDK1.3.1之后才有效），當此參數被設置之后，jvm將不接收控制台的控制handler，以防止與在后台以服務形式運行的JVM沖突；

-Xprof
 跟蹤正運行的程序，並將跟蹤數據在標准輸出輸出；適合於開發環境調試。

-Xnoclassgc
 關閉針對class的gc功能；因為其阻止內存回收，所以可能會導致OutOfMemoryError錯誤，慎用；

-Xincgc
 開啟增量gc（默認為關閉）；這有助於減少長時間GC時應用程序出現的停頓；但由於可能和應用程序並發執行，所以會降低CPU對應用的處理能力。

-Xloggc:file
 與-verbose:gc功能類似，只是將每次GC事件的相關情況記錄到一個文件中，文件的位置最好在本地，以避免網絡的潛在問題。
 若與verbose命令同時出現在命令行中，則以-Xloggc為准。

比較詳細的非Stable參數總結，請參考Java 6 JVM參數選項大全（中文版），
對於非Stable參數，使用方法有4種：

• -XX:+<option> 啟用選項
• -XX:-<option> 不啟用選項
• -XX:<option>=<number> 給選項設置一個數字類型值，可跟單位，例如 32k, 1024m, 2g
• -XX:<option>=<string> 給選項設置一個字符串值，例如-XX:HeapDumpPath=./dump.core

首先介紹性能參數，性能參數往往用來定義內存分配的大小和比例，相比於行為參數和調試參數，一個比較明顯的區別是性能參數后面往往跟的有數值，常用如下：

參數及其默認值	描述
-XX:NewSize=2.125m	新生代對象生成時占用內存的默認值
-XX:MaxNewSize=size	新生成對象能占用內存的最大值
-XX:MaxPermSize=64m	方法區所能占用的最大內存（非堆內存）
-XX:PermSize=64m	方法區分配的初始內存
-XX:MaxTenuringThreshold=15	對象在新生代存活區切換的次數（堅持過MinorGC的次數，每堅持過一次，該值就增加1），大於該值會進入老年代
-XX:MaxHeapFreeRatio=70	GC后java堆中空閑量占的最大比例，大於該值，則堆內存會減少
-XX:MinHeapFreeRatio=40	GC后java堆中空閑量占的最小比例，小於該值，則堆內存會增加
-XX:NewRatio=2	新生代內存容量與老生代內存容量的比例
-XX:ReservedCodeCacheSize= 32m	保留代碼占用的內存容量
-XX:ThreadStackSize=512	設置線程棧大小，若為0則使用系統默認值
-XX:LargePageSizeInBytes=4m	設置用於Java堆的大頁面尺寸
-XX:PretenureSizeThreshold= size	大於該值的對象直接晉升入老年代（這種對象少用為好）
-XX:SurvivorRatio=8	Eden區域Survivor區的容量比值，如默認值為8，代表Eden：Survivor1：Survivor2=8:1:1

 

常用的行為參數，主要用來選擇使用什么樣的垃圾收集器組合，以及控制運行過程中的GC策略等：

參數及其默認值	描述
-XX:-UseSerialGC	啟用串行GC，即采用Serial+Serial Old模式
-XX:-UseParallelGC	啟用並行GC，即采用Parallel Scavenge+Serial Old收集器組合（-Server模式下的默認組合）
-XX:GCTimeRatio=99	設置用戶執行時間占總時間的比例（默認值99，即1%的時間用於GC）
-XX:MaxGCPauseMillis=time	設置GC的最大停頓時間（這個參數只對Parallel Scavenge有效）
-XX:+UseParNewGC	使用ParNew+Serial Old收集器組合
-XX:ParallelGCThreads	設置執行內存回收的線程數，在+UseParNewGC的情況下使用
-XX:+UseParallelOldGC	使用Parallel Scavenge +Parallel Old組合收集器
-XX:+UseConcMarkSweepGC	使用ParNew+CMS+Serial Old組合並發收集，優先使用ParNew+CMS，當用戶線程內存不足時，采用備用方案Serial Old收集。
-XX:-DisableExplicitGC	禁止調用System.gc()；但jvm的gc仍然有效
-XX:+ScavengeBeforeFullGC	新生代GC優先於Full GC執行

 

常用的調試參數，主要用於監控和打印GC的信息：

參數及其默認值	描述
-XX:-CITime	打印消耗在JIT編譯的時間
-XX:ErrorFile=./hs_err_pid<pid>.log	保存錯誤日志或者數據到文件中
-XX:-ExtendedDTraceProbes	開啟solaris特有的dtrace探針
-XX:HeapDumpPath=./java_pid<pid>.hprof	指定導出堆信息時的路徑或文件名
-XX:-HeapDumpOnOutOfMemoryError	當首次遭遇OOM時導出此時堆中相關信息
-XX:OnError="<cmd args>;<cmd args>"	出現致命ERROR之后運行自定義命令
-XX:OnOutOfMemoryError="<cmd args>;<cmd args>"	當首次遭遇OOM時執行自定義命令
-XX:-PrintClassHistogram	遇到Ctrl-Break后打印類實例的柱狀信息，與jmap -histo功能相同
-XX:-PrintConcurrentLocks	遇到Ctrl-Break后打印並發鎖的相關信息，與jstack -l功能相同
-XX:-PrintCommandLineFlags	打印在命令行中出現過的標記
-XX:-PrintCompilation	當一個方法被編譯時打印相關信息
-XX:-PrintGC	每次GC時打印相關信息
-XX:-PrintGC Details	每次GC時打印詳細信息
-XX:-PrintGCTimeStamps	打印每次GC的時間戳
-XX:-TraceClassLoading	跟蹤類的加載信息
-XX:-TraceClassLoadingPreorder	跟蹤被引用到的所有類的加載信息
-XX:-TraceClassResolution	跟蹤常量池
-XX:-TraceClassUnloading	跟蹤類的卸載信息
-XX:-TraceLoaderConstraints	跟蹤類加載器約束的相關信息

二、啟動內存分配

關於GC有一個常見的疑問是，在啟動時，我的內存如何分配？經過前面的學習，已經很容易知道，用-Xmn，-Xmx，-Xms，-Xss，-XX:NewSize，-XX:MaxNewSize，-XX:MaxPermSize，-XX:PermSize，-XX:SurvivorRatio，-XX:PretenureSizeThreshold，-XX:MaxTenuringThreshold就基本可以配置內存啟動時的分配情況。但是，具體配置多少？設置小了，頻繁GC（甚至內存溢出），設置大了，內存浪費。結合前面對於內存區域和其作用的學習，盡量考慮如下建議：

1. -XX:PermSize盡量比-XX:MaxPermSize小，-XX:MaxPermSize>= 2 * -XX:PermSize, -XX:PermSize> 64m，一般對於4G內存的機器，-XX:MaxPermSize不會超過256m；
2. -Xms =  -Xmx（線上Server模式），以防止抖動，大小受操作系統和內存大小限制，如果是32位系統，則一般-Xms設置為1g-2g（假設有4g內存），在64位系統上，沒有限制，不過一般為機器最大內存的一半左右；
3. -Xmn，在開發環境下，可以用-XX:NewSize和-XX:MaxNewSize來設置新生代的大小（-XX:NewSize<=-XX:MaxNewSize），在生產環境，建議只設置-Xmn，一般-Xmn的大小是-Xms的1/2左右，不要設置的過大或過小，過大導致老年代變小，頻繁Full GC，過小導致minor GC頻繁。如果不設置-Xmn，可以采用-XX:NewRatio=2來設置，也是一樣的效果；
4. -Xss一般是不需要改的，默認值即可。
5. -XX:SurvivorRatio一般設置8-10左右，推薦設置為10，也即：Survivor區的大小是Eden區的1/10，一般來說，普通的Java程序應用，一次minorGC后，至少98%-99%的對象，都會消亡，所以，survivor區設置為Eden區的1/10左右，能使Survivor區容納下10-20次的minor GC才滿，然后再進入老年代，這個與 -XX:MaxTenuringThreshold的默認值15次也相匹配的。如果XX:SurvivorRatio設置的太小，會導致本來能通過minor回收掉的對象提前進入老年代，產生不必要的full gc；如果XX:SurvivorRatio設置的太大，會導致Eden區相應的被壓縮。
6. -XX:MaxTenuringThreshold默認為15，也就是說，經過15次Survivor輪換（即15次minor GC），就進入老年代， 如果設置的小的話，則年輕代對象在survivor中存活的時間減小，提前進入年老代，對於年老代比較多的應用，可以提高效率。如果將此值設置為一個較大值，則年輕代對象會在Survivor區進行多次復制，這樣可以增加對象在年輕代的存活時間，增加在年輕代即被回收的概率。需要注意的是，設置了  -XX:MaxTenuringThreshold，並不代表着，對象一定在年輕代存活15次才被晉升進入老年代，它只是一個最大值，事實上，存在一個動態計算機制，計算每次晉入老年代的閾值，取閾值和MaxTenuringThreshold中較小的一個為准。
7. -XX:PretenureSizeThreshold一般采用默認值即可。

參見:http://my.oschina.net/chape/blog/200790?fromerr=t037M1rv

調優方法

一切都是為了這一步，調優，在調優之前，我們需要記住下面的原則：

1. 多數的Java應用不需要在服務器上進行GC優化；
2. 多數導致GC問題的Java應用，都不是因為我們參數設置錯誤，而是代碼問題；
3. 在應用上線之前，先考慮將機器的JVM參數設置到最優（最適合）；
4. 減少創建對象的數量；
5. 減少使用全局變量和大對象；
6. GC優化是到最后不得已才采用的手段；
7. 在實際使用中，分析GC情況優化代碼比優化GC參數要多得多；

GC優化的目的有兩個（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）：

• 將轉移到老年代的對象數量降低到最小；
• 減少full GC的執行時間；

為了達到上面的目的，一般地，你需要做的事情有：

• 減少使用全局變量和大對象；
• 調整新生代的大小到最合適；
• 設置老年代的大小為最合適；
• 選擇合適的GC收集器；

在上面的4條方法中，用了幾個“合適”，那究竟什么才算合適，一般的，請參考上面“收集器搭配”和“啟動內存分配”兩節中的建議。但這些建議不是萬能的，需要根據您的機器和應用情況進行發展和變化，實際操作中，可以將兩台機器分別設置成不同的GC參數，並且進行對比，選用那些確實提高了性能或減少了GC時間的參數。

真正熟練的使用GC調優，是建立在多次進行GC監控和調優的實戰經驗上的，進行監控和調優的一般步驟為：
1，監控GC的狀態
使用各種JVM工具，查看當前日志，分析當前JVM參數設置，並且分析當前堆內存快照和gc日志，根據實際的各區域內存划分和GC執行時間，覺得是否進行優化；
2，分析結果，判斷是否需要優化
如果各項參數設置合理，系統沒有超時日志出現，GC頻率不高，GC耗時不高，那么沒有必要進行GC優化；如果GC時間超過1-3秒，或者頻繁GC，則必須優化；
注：如果滿足下面的指標，則一般不需要進行GC：

 

• Minor GC執行時間不到50ms；
• Minor GC執行不頻繁，約10秒一次；
• Full GC執行時間不到1s；
• Full GC執行頻率不算頻繁，不低於10分鍾1次；

3，調整GC類型和內存分配
如果內存分配過大或過小，或者采用的GC收集器比較慢，則應該優先調整這些參數，並且先找1台或幾台機器進行beta，然后比較優化過的機器和沒有優化的機器的性能對比，並有針對性的做出最后選擇；
4，不斷的分析和調整
通過不斷的試驗和試錯，分析並找到最合適的參數
5，全面應用參數
如果找到了最合適的參數，則將這些參數應用到所有服務器，並進行后續跟蹤。

調優實例

上面的內容都是紙上談兵，下面我們以一些真實例子來進行說明：
實例1：
筆者昨日發現部分開發測試機器出現異常：java.lang.OutOfMemoryError: GC overhead limit exceeded，這個異常代表：GC為了釋放很小的空間卻耗費了太多的時間，其原因一般有兩個：1，堆太小，2，有死循環或大對象；
筆者首先排除了第2個原因，因為這個應用同時是在線上運行的，如果有問題，早就掛了。所以懷疑是這台機器中堆設置太小；
使用ps -ef |grep "java"查看，發現：

該應用的堆區設置只有768m，而機器內存有2g，機器上只跑這一個java應用，沒有其他需要占用內存的地方。另外，這個應用比較大，需要占用的內存也比較多；
筆者通過上面的情況判斷，只需要改變堆中各區域的大小設置即可，於是改成下面的情況：

 

跟蹤運行情況發現，相關異常沒有再出現；

實例2：（http://www.360doc.com/content/13/0305/10/15643_269388816.shtml）
一個服務系統，經常出現卡頓，分析原因，發現Full GC時間太長：
jstat -gcutil:
S0     S1    E     O       P        YGC YGCT FGC FGCT  GCT
12.16 0.00 5.18 63.78 20.32  54   2.047 5     6.946  8.993 
分析上面的數據，發現Young GC執行了54次，耗時2.047秒，每次Young GC耗時37ms，在正常范圍，而Full GC執行了5次，耗時6.946秒，每次平均1.389s，數據顯示出來的問題是：Full GC耗時較長，分析該系統的是指發現，NewRatio=9，也就是說，新生代和老生代大小之比為1:9，這就是問題的原因：
1，新生代太小，導致對象提前進入老年代，觸發老年代發生Full GC；
2，老年代較大，進行Full GC時耗時較大；
優化的方法是調整NewRatio的值，調整到4，發現Full GC沒有再發生，只有Young GC在執行。這就是把對象控制在新生代就清理掉，沒有進入老年代（這種做法對一些應用是很有用的，但並不是對所有應用都要這么做）

實例3：
一應用在性能測試過程中，發現內存占用率很高，Full GC頻繁，使用sudo -u admin -H  jmap -dump:format=b,file=文件名.hprof pid 來dump內存，生成dump文件，並使用Eclipse下的mat差距進行分析，發現：

 

從圖中可以看出，這個線程存在問題，隊列LinkedBlockingQueue所引用的大量對象並未釋放，導致整個線程占用內存高達378m，此時通知開發人員進行代碼優化，將相關對象釋放掉即可。