cpu飙高排查过程

找到 Java 应用的进程 id：

jps
使用 top 命令动态展示该 Java 应用下的 CPU 占用高的子进程：

top -Hp 1

发现进程号为 355 和 356 的进程 CPU 已经飙到 70% 多！

因为 jstack 打印堆栈信息的线程 id 是 16 进制，所以需要先将线程 id 转换为 16 进制格式数据：

printf “%x” 355
得到结果为 163

使用 jstack 命令打印线程堆栈信息：

jstack 1 | grep 163

果然是 GC 线程导致 CPU 飙高，可以得出是空闲内存不足（Java 堆区没有空间分配新对象）导致频繁 GC。

再通过 jstat 命令查看 GC 情况：

jstat -gcutil 1 2000

                                                      （内存占用曲线）

看到发生 Full GC 一百五十多次，并且内存曲线一直呈上升趋势无降低，基本可以判断发生了内存泄漏。

但是内存泄漏分为 堆内内存泄漏 和 堆外内存泄漏，需要再次判断下（ -heap 参数打印出 Java 堆详细信息）：

jmap -heap 1

看到 CMS 垃圾收集的区域（也就是老年代）占用达到 99.999%，庆幸发生的是堆内内存泄漏，可控的！

所以我们需要将堆快照 dump 下来进行内存分析看下到底是哪个地方导致的内存泄漏。

使用 jmap -dump 生成 Java 堆转储快照（live 参数代表 dump 存活对象）：

jmap -dump:live,format=b,file=OOMDump.bin 1
提示“Heap dump file created”代表生成完成，将堆 dump 文件 scp 到本地。

我们使用 Java 自带内存分析工具 jvisualvm 来分析下内存泄漏，本地终端执行启动 jvisua