性能監控和故障處理

一、GC日誌

Allocation Failure

大部分GC，尤其是YGC，都是因為分配內存失敗才觸發的

Prommotion failed

由於救助空間不夠，從而向年老代轉移對象，年老代沒有足夠的空間來容納這些對象，導致一次full gc的產生

Concurrent mode failed

由於CMS回收年老代的速度太慢，導致年老代在CMS完成前就被沾滿，引起full gc，避免這個現象的產生就是調小-XX:CMSInitiatingOccupancyFraction參數的值

Prommotion failed的日誌輸出大概是這樣：

[ParNew (promotion failed): 320138K->320138K(353920K), 0.2365970 secs]42576.951: [CMS: 1139969K->1120688K( 166784K), 9.2214860 secs] 1458785K->1120688K(2520704K), 9.4584090 secs]

這個問題的產生是由於救助空間不夠，從而向年老代轉移對象，年老代沒有足夠的空間來容納這些對象，導致一次full gc的產生。

解決這個問題的辦法有兩種完全相反的傾向：增大救助空間、增大年老代或者去掉救助空間。

1、增大救助空間就是調整-XX:SurvivorRatio參數，這個參數是Eden區和Survivor區的大小比值，默認是32，也就是說Eden區是 Survivor區的32倍大小，要注意Survivo是有兩個區的，因此Surivivor其實占整個young genertation的1/34。調小這個參數將增大survivor區，讓對象盡量在survitor區呆長一點，減少進入年老代的對象。

2、去掉救助空間的想法是讓大部分不能馬上回收的數據儘快進入年老代，加快年老代的回收頻率，減少年老代暴漲的可能性，這個是通過將-XX:SurvivorRatio 設置成比較大的值（比如65536)來做到。在我們的應用中，將young generation設置成256M，這個值相對來說比較大了，而救助空間設置成默認大小(1/34)，從壓測情況來看，沒有出現prommotion failed的現象，年輕代比較大，從GC日誌來看，minor gc的時間也在5-20毫秒內，還可以接受，因此暫不調整。

Concurrent mode failed的產生是由於CMS回收年老代的速度太慢，導致年老代在CMS完成前就被沾滿，引起full gc，避免這個現象的產生就是調小-XX:CMSInitiatingOccupancyFraction參數的值，讓CMS更早更頻繁的觸發，降低年老代被沾滿的可能。我們的應用暫時負載比較低，在生產環境上年老代的增長非常緩慢，因此暫時設置此參數為80。在壓測環境下，這個參數的表現還可以，沒有出現過Concurrent mode failed。

二、常用命令

功能和ps類似，列出正在運行的虛擬機進程，並顯示虛擬機執行主類，例如jps -l

用於監控虛擬機各種運行狀態信息的命令行工具，顯示內存、垃圾收集等運行數據

./jstat -gcutil 28223

S0 S1 E O P YGC YGCT FGC FGCT GCT

0.00 20.64 54.63 64.37 15.30 19595 359.571 107 14.881 374.452

程序運行以來共發生MinorGC（YGC）多少次，耗時多少秒（YGCT），發生FullGC（FGC）多少次，耗時多少秒（FGCT），所有GC總耗時（GCT）多少秒

./jstat -gc 250 20

查看堆內存對象詳情：

./jmap -histo 11153head -n 50

查看jvm內存情況：

./jmap -heap 28223

列印java堆perm區的classloader統計

./jmap -permstat 25092

Heap Configuration:

MinHeapFreeRatio = 40

MaxHeapFreeRatio = 70

NewRatio = 2

SurvivorRatio = 8

PermSize = 402653184 (384.0MB)

MaxPermSize = 402653184 (384.0MB)

G1HeapRegionSize = 0 (0.0MB)

Heap Usage:

New Generation (Eden + 1 Survivor Space):

Eden Space:

used = 20044296 (19.11573028564453MB)

From Space:

To Space:

used = 0 (0.0MB)

0.0% used

concurrent mark-sweep generation:

Perm Generation:

命令用於生成虛擬機當前時刻的線程快照，主要目的是定位線程出現長時間停頓的原因

JConsole內存監控、線程監控

VisualVM多合一故障處理工具、安裝插件後可以生成、瀏覽堆轉儲快照、分析程序性能、BTrace動態日誌追蹤

需要打開gc日誌並讀懂gc日誌：-XX:PrintHeapAtGC -XX:+PrintGCDetails-XX:+PrintGCDateStamps

給 JVM 設置-XX:+HeapDumpOnOutOfMemoryError參數，讓 JVM 碰到 OOM 場景時輸出 dump 信息。

說明:OOM 的發生是有概率的，甚至有規律地相隔數月才出現一例，出現時的現場信息對查錯 非常有價值。

三、常見問題定位過程

頻繁GC問題或內存溢出問題

一、使用jps查看線程ID

二、使用jstat -gc 3331 250 20 查看gc情況，一般比較關注PERM區的情況，查看GC的增長情況。

三、使用jstat -gccause：額外輸出上次GC原因

四、使用jmap -dump:format=b,file=heapDump 3331生成堆轉儲文件

五、使用jhat或者可視化工具（Eclipse Memory Analyzer 、IBM HeapAnalyzer）分析堆情況。

六、結合代碼解決內存溢出或泄露問題。

死鎖問題

一、使用jps查看線程ID

二、使用jstack 3331：查看線程情況

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！