Java效能調優相關命令摘要
1 檢視JVM引數
jps -v 598 xxx.jar -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.login.config=xxxConfig -Djava.security.auth.login.config=xxxx -Dcom.sun.management.jmxremote.ssl=false -Xms10g -Xmx10g -Xloggc:/home/shared/log/gc.log.2018-11-15-14-07 -XX:+PrintGCDateStamps -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:MetaspaceSize=256m -XX:-OmitStackTraceInFastThrow -XX:+PrintGCDetails -verbose:gc
2 檢視JVM啟動時命令列引數
598 xxx.jar --spring.profiles.active=xxxx
3 快速診斷gc效能
jstat -gc -t pid 1s Timestamp S0C S1C S0U S1U EC EU OC OU MC MU CCSC CCSU YGC YGCT FGC FGCT GCT 2556.3 0.0 57344.0 0.0 57344.0 495616.0 147456.0 9932800.0 4523270.2 120064.0 114879.9 13312.0 12364.5 481 100.840 0 0.000 100.840 2557.4 0.0 57344.0 0.0 57344.0 495616.0 385024.0 9932800.0 4523270.2 120064.0 114879.9 13312.0 12364.5 481 100.840 0 0.000 100.840 2558.4 0.0 53248.0 0.0 53248.0 499712.0 147456.0 9932800.0 4564299.0 120064.0 114879.9 13312.0 12364.5 482 100.932 0 0.000 100.932
第1列Timestamp是程序已經執行的時間(秒)
接下來S0/1C/U這4列分別兩個Survivor區容量(Capcity)、已使用量(Usage)。不過我這裡用的是G1,所以總有一組是0,另一組是全滿,對於G1這個參考意義不大。
還有一個重要資料是OU,表示老年代已使用的時間。可以沒隔一段時間執行一次,如果OU的最小值(最小想對於每組之內)一直在增長,那麼可能發生了記憶體洩漏。
4 堆分析利器jmap
jmap有多種執行模式,常用的有
- -clstats 列印被載入的類資訊
- -finalizerinfo 列印所有待finalize的物件
- -histo(:live) 統計各個類的數目以及佔用記憶體,帶live是隻統計存活的。
- -dump(:live) 匯出Java虛擬機器的堆快照,同樣live是隻存活的。
5 執行緒CPU分析
jstack,可以列印各個執行緒id以及對應的執行情況,除了RUN和BLOCK外,有的會提示死鎖,此時就是有問題的了。
另外結合top -H -p pid可以檢視每個執行緒的CPU佔用率,再結合jstack中執行狀態,就能大致得知哪裡是執行瓶頸(判斷死迴圈很有用)。
上面這些摘錄自Oracle研究院鄭博士的專欄,感興趣的話,可以掃碼購買。