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有多种运行模式,常用的有
5 线程CPU分析
jstack,可以打印各个线程id以及对应的运行情况,除了RUN和BLOCK外,有的会提示死锁,此时就是有问题的了。
另外结合top -H -p pid可以查看每个线程的CPU占用率,再结合jstack中运行状态,就能大致得知哪里是运行瓶颈(判断死循环很有用)。
上面这些摘录自Oracle研究院郑博士的专栏,感兴趣的话,可以扫码购买。