利用這個case來總結一下線上如何來排查問題找到代碼BUG並修復的。
1. Java heap dump日誌分析
一般分析內存溢出分析哪些應用佔用內存比較多情況有用
jmap -dump:format=b,file=path pid 默認將堆全部dump下來jmap -dump:live,format=b,file=path pid 只dump還存活的沒gc掉的對象
如果發現fgc不直不掉的話就需要用這個來dump一把,打開的軟件Eclipse Mat
2. Java JVM GC日誌分析
E eden區，所有新對象在這裏面產生。這裏面很快就被minor gc
S0 倖存者O區E區gc不掉的會被放進到這個區
S1 倖存者1區
S0區gc剩下的對象進入到這個區
這三個區合起來叫young 區。
O old區經過多次minor gc不掉的會放到這個區。只有fullgc才能回收
一般線上是92%開始full gc
P perm區方法區。如果用了AOP就會有變化一般不會有變化
YGC 從JVM啓動到目前minor gc次數
YGCT minor gc所消耗的時間
FCG 如果0區一直gc不掉會不斷做gc
FGCT full gc所消耗的時間
3. Java thread dump日誌分析
$jstack pid 打印當前運行的java線程棧信息
1,死鎖 Deadlock(重要)
2,等待資源 Waiting on condition (重要)
3,等待獲取監視器waiting on monitor entry
4,阻塞Blocked
5,執行中Runnable
6,暫停Suspended
7,對象等待中Object.wait()或TIMED_WAITING
8,停止Parked
"Xmemcached-Reactor-15" prio=10 tid=0x00002aaac15ad000 nid=0x2256 runnable [0x0000000043077000]
java.lang.Thread.State: RUNNABLE
"Xmemcached-Reactor-15" 線程名稱。用戶自己的程序最好是線程名稱
prio=10 線程優先級默認是5
tid=0x00002aaac15ad000 唯一標識
0x2256 對應系統線程的id和top出來看到的pid是對應的（十進制轉16進制）
RUNNABLE線程狀態
4. JVM crash日誌分析
Jvm crash時會在工作目錄下產生一個日誌文件，也可以通過參數指定。如-XX:ErrorFile=/home/admin/hs_error_%p.log導致crash的原因有多種：
1、Jvm本身的Bug
2、應用程序有bug
什麼情況不會生成error文件？
linux內核在發生OOM的時候會強制kill一些進程，可以在/var/log/messages中查找，也可以在/var/log/kernel中看到。
5. 常用的分析命令
top -H -P $PID 動態的看到java線程的消耗情況
top -H -b -n 1 -p $PID 打印一次java線程情況jstack $PID 打印當前運行的java線程棧信息（建議打印2，3次）
jstat -gcutil $PID <毫秒數> 動態的觀察jvm內存各區情況，主要看下FGC與YGC的使用情況!