jstat -gcutil <PID> 1s 次數 查看內存堆棧
[jimw@TEST-2 /]$ jstat -gcutil 21360 1s 3
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 35.53 83.18 5.52 57.32 68307 2722.980 0 0.000 2722.980
32.95 0.00 3.18 5.52 57.32 68308 2723.043 0 0.000 2723.043
32.95 0.00 7.29 5.52 57.32 68308 2723.043 0 0.000 2723.043
通俗點來解釋（可能不能達到標准的說法）
S0 S1 ,E,OP,YGC都是百分比的形式反饋
其中S0+S1+E 就是當前內存棧 所有利用的內存收集
O 則是舊數據的回收
當FGC一直彪高並且前者數據很大的時候，那么就需要檢查代碼是否正常，一般導致這樣的情況都是內存溢出。
並且可以檢查一下內存是否有加大。
參考：
之前遇到的一個坑，就是加大內存后，還是發現內存占用很大伴隨着也會出現cpu過高導致程序異常的慢，因此需要用jvm的內置查詢內存過大跟cpu過高的問題。
1. 查找進程
top查看進程占用資源情況
2.查找線程
使用top -H -p <pid>查看線程占用情況
3.查找java的堆棧信息
將線程id轉換成十六進制
#printf %x 15664
#3d30
然后再使用jstack查詢線程的堆棧信息
語法：jstack <pid> | grep -a 線程id（十六進制）
jstack <pid> | grep -A10 3d30>>/tmp/pid.log
接下來就可以找到代碼所在的問題了。