JVM 之 Linux定位CPU过高问题并优化

项目部署以后出行卡顿现象，所以对问题进行了排查，记录一下排查过程

1.找进程
top

可以发现，是Java进程导致的CPU过高，致使系统卡顿

2.找线程
ps -mp pid -o THREAD,tid,time

发现占比最大的线程

3.线程id转换16进制
printf “%x\n” pid

得到6a33，方便下一步排查

4.查询代码位置
jstack pid|grep tid -A 30

发现全是GC线程

5.查看gc频率
jstat -gcutil pid 时间间隔 打印次数

发现Eden很满，不断增长，GC次数过多
垃圾回收统计
S0: Survivor space 0 utilization as a percentage of the space’s current capacity. 幸存者区0
S1: Survivor space 1 utilization as a percentage of the space’s current capacity. 幸存者区1
E: Eden space utilization as a percentage of the space’s current capacity. 伊甸园区
O: Old space utilization as a percentage of the space’s current capacity. 老年代
M: Metaspace utilization as a percentage of the space’s current capacity. 元空间
CCS: Compressed class space utilization as a percentage. 压缩类空间利用率为百分比。
YGC: Number of young generation GC events. 年轻一代GC事件的数量。
YGCT: Young generation garbage collection time. 年轻一代垃圾收集时间
FGC: Number of full GC events. 完整的GC事件的数量。
FGCT: Full garbage collection time. 完全垃圾收集时间。
GCT: Total garbage collection time. 垃圾回收总时间。

jstat -gccapacity pid
堆内存查看
NGCMN：新生代最小容量
NGCMX：新生代最大容量
NGC：当前新生代容量
S0C：第一个幸存区大小
S1C：第二个幸存区的大小
EC：伊甸园区的大小
OGCMN：老年代最小容量
OGCMX：老年代最大容量
OGC：当前老年代大小
OC:当前老年代大小
MCMN:最小元数据容量
MCMX：最大元数据容量
MC：当前元数据空间大小
CCSMN：最小压缩类空间大小
CCSMX：最大压缩类空间大小
CCSC：当前压缩类空间大小
YGC：年轻代gc次数
FGC：老年代GC次数

6.dump堆文件
jstack pid >>jstack.out

7.查找dump文件
find . -name “jstack.out”
这步可有可无，生成在当前目录


8.IBM Thread and Monitor Dump Analyzer for Java
可视化工具分析dump文件

查看结果还算正常

9.尝试调整JVM参数
查看JVM参数，发现默认才512m

查看系统总内存
cat /proc/meminfo查看linux系统内存大小的详细信息

发现总内存约64G
将-Xmx 最大堆内存设置为1024m，扩大一倍看看

重启服务发现GC频率明显下降，恢复正常，满足以下标准

如果各项参数设置合理，系统没有超时日志出现，GC频率不高，GC耗时不高，那么没有必要进行GC优化；如果GC时间超过1〜3 秒，或者频繁G C
,则必须优化。如果满足下面的指标，则一般不需要进行GC: ■ Minor GC执行时间不到50ms; ■ Minor
GC执行不频繁，约10秒一次； ■ Full GC执行时间不到1s; ■ Full GC执行频率不算频繁，不低于10分钟1次。