CPU告警排查思路，正常情况就是如下两种情况
- 执行任务的java线程本身存在bug，死循环或者操作本身耗cpu，导致cpu占用过高
- jvm发生频繁gc，导致cpu过高
查看耗时较高的进程
- top命令，并按大写P以cpu利用率排序，确定cpu占用最高的进程为 java进程
- top -H -p [进程id]，注意：此时的PID为线程ID，如下图所示
- 计算java线程id的16进制值，用jstack看到的线程快照中，线程ID需要转换成小写十六进制值
- 可以借助在线转换工具：十进制转换 - 在线进制转换器
- linux系统也可以使用如下命令转换 printf "%x\n" [线程ID]
printf "%x\n" 22304使用Jstack查看线程快照
#grep的 -B n 前n行
#grep的 -C n 前后各n行
#grep的 -A n 后n行
jstack [进程ID] |grep [转换后的线程ID] -A 30
分析上图发现，查看完整堆栈定位代码位置，该线程进本都在执行
com.daojia.hub.util.CaseNodeParseUtil.addNodeToChildrenIfParentIdEqual(CaseNodeParseUtil.java:1363)
后续进一步分析，需要结合业务代码查看该部分是否存在耗时
查看GC情况
- 首先使用top查看当前内存的使用情况
- 查看gc次数，使用命令 jstat -gc [Java进程ID]：
结合上图可知YGC次数1232，FGC共468次
如果GC次数很多的情况，基本可以说明存在频繁GC导致cpu占用高的问题
GC参数说明
S0C：第一个幸存区的大小
S1C：第二个幸存区的大小
S0U：第一个幸存区的使用大小
S1U：第二个幸存区的使用大小
EC：伊甸园区的大小
EU：伊甸园区的使用大小
OC：老年代大小
OU：老年代使用大小
MC：方法区大小
MU：方法区使用大小
CCSC:压缩类空间大小
CCSU:压缩类空间使用大小
YGC：年轻代垃圾回收次数
YGCT：年轻代垃圾回收消耗时间
FGC：老年代垃圾回收次数
FGCT：老年代垃圾回收消耗时间
GCT：垃圾回收消耗总时间
使用命令dump 内存堆的存储快照，命令如下
jmap -dump:format=b,file=/tmp/mem.hprof [进程ID]
使用内存分析工具，如Eclipse Memory Analyzer等分析mem.hprof文件，分析内存哪部分占用大，存在内存泄露，导致空间无法释放。
