前言
首先建议先简单了解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