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