前言
首先建议先简单了解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 ：打印每个class的实例数⽬、内存占用、类全名信息
jmap -histo:live pid > 1.txt
然后查看1.txt
less 1.txt 或者cat 1.txt
4. jmap -dump:live
同样会触发Full GC
jmap -dump:live,format=b,file=heap.bin <pid>：将当前存活对象dump到⽂件
可以导入到本地的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