简单总结Linux上排查JVM问题，cpu飙升或者内存不足

前言
首先建议先简单了解JVM的内存机制，以及GC垃圾回收机制
初步了解jvm的内存分配，gc以及简单的jvm内存配置

以下j开头的命令基本都是java命令，如果没有设置全局环境变量，需要加上${java_home}全路径。如/usr/local/jdk8/java/bin/jmap pid

一、内存不足

1. 查看pid

ps -ef|grep java 或 jps -lv  

24130 就是pid

2. jmap -heap查看堆内存

jmap -heap pid 

上面就是jvm的堆内存配置信息，以及新生代，老年代，永久代的内存最大值和当前使用值

3. jmap -histo:live

这里会触发Full GC

jmap -histo:live pid > 1.txt 

然后查看1.txt
less 1.txt 或者cat 1.txt

4. jmap -dump:live

同样会触发Full GC

可以导入到本地的jvisual进行分析，这个工具在jdk的java/bin目录下

可以查看类的实例数和所占内存大小，分析哪个类异常

二、cpu飙升

1. top命令

top命令查看cpu，内存情况

top 

找到占用cpu高的pid

top -Hp pid 

再找出占用高的pid

2. jstack查看对账信息

假如通过Top命令，找到了占用cpu高的java应用的pid是24130

那么

jstack [-l] pid -l是打印出线程信息 

jstack -l 24130

假如我们上面 top -Hp 命令找到的占用cpu高的pid是24190

先转成16进制

printf "%x\n" s 

printf “%x\n” 24190

然后

jstack -l javapid | grep '0x'+十六进制pid -A10 --color -A是打印符合条件后n行,-C是环绕n行,-B是之前n行 

jstack -l 24130|grep ‘0x5e7e’ -A10 --color

根据堆栈信息和线程状态，分析cpu占用原因。
如果线程状态是BLOCKED，就是线程阻塞中

三、gc和类加载情况

1. jstat -class

jstat -class pid 

• Loaded:加载class的数量
• Bytes：所占用空间大小
• Unloaded：未加载数量
• Bytes:未加载占用空间
• Time：时间s

编译统计

jstat -compiler pid 

2. jstat -gc

伊甸园区（Eden区）
幸存区（survivor区）

jstat -gc pid 1000  1000表示1秒刷新一次 

S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间 ，秒
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间 ，秒
GCT：垃圾回收消耗总时间 ，秒

总体垃圾回收统计

jstat -gcutil pid 1000 

S0：幸存1区当前使用比例
S1：幸存2区当前使用比例
E：伊甸园区使用比例
O：老年代使用比例
M：元数据区使用比例
CCS：压缩使用比例
YGC：年轻代垃圾回收次数
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间

其他:

# 新生代垃圾回收统计 jstat -gcnew  pid    #老年代垃圾回收统计 jstat -gcold pid  

观察

通过观察YGC和FGC的次数和频率，以及FGCT / FGC 单位耗时，YGCT / YGC 单位耗时，判断内存是否足够。

如果频繁的FULL GC说明内存分配不合理。堆内存很可能分配太小了。并且GC会导致除了垃圾收集收集器线
程之外的线程都被挂起，频繁GC毫无疑问是影响程序的

观察Eden区的内存占用和老年代的内存占用，如果持续的增加说明很可能存在内存泄漏问题，可能导致OOM

来源：51CTO

作者：zzzgd_666

链接：https://blog.csdn.net/zzzgd_666/article/details/100781696