CPU占用过高排查实战 原来这么简单

代码介绍：

jdk提供的工具：

1、在Linux中启动项目：java -cp ref-jvm.jar -XX:+PrintGC -Xms200M -Xmx200M ex13.FullGCProblem

2、top命令，实时显示进程CPU百分比和内存使用情况：可以发现进程7498 占用CPU比较高

等待一段时间：发现CPU使用率在逐渐增加

jinfo:显示JVM参数设置信息

jmap -heap 7498 :可以查看内存使用情况

在不进行任何垃圾回收器指定情况的比例1:1:1

一段时间后 CPU占比很高了

top -p 7498:单独显示7498进程占比CPU

在监控界面输入H，获取当前进程下的所有线程信息

jstack 7498：输出线程信息，nid为16进制

将7500/7501换算成16进制1D4C/1D4D,在界面中查找，问题定位到CPU100%是疯狂的垃圾回收的线程占据的

jstat -gc 7498 2000 10:两秒钟刷新一次GC信息，一共查询10次

各个字段的含义如下：

不够直观，换个方式输出：jstat -gc 7498 5000 20 | awk '{print 13,14,15,16,

可以发现Full GC在增加，，说明内存不够了

jmap -heap 7498,查看堆内存情况，发现老年代使用率很大了，可能发生了内存泄漏

现在我们定位为是内存问题，CPU100%只是它的体现

jmap -histo 7498 | head -20:显示堆空间对应7498进程对应对象占用大小

问题总结（找到问题）

一般来说，前面那几行，就可以看出，到底是哪些对象占用了内存，这些对象回收不掉，导致了Full GC 里面还有OOM 任务数多于线程数，那么任务会进入阻塞队列，就是一个队列，因为代码中任务数一直多于线程数，所以每0.1s，就会有50个任务进入阻塞对象，50个任务底下有对象，至少对象送进去了，但是没执行，所以导致对象一直都在，同时还回收不了。 为什么回收不了，Executor是一个GCRoots,所以堆中，就会有60多万个对象，阻塞队列中60多万个任务，futureTask，并且这些对象还回收不了。

总结

在JVM出现性能问题的时候（表现上是CPU100%，内存一直占用） 1、出现CPU100%，要从两个角度出发，一个有可能是业务线程疯狂运行，比如说死循环，还有就是GC线程在疯狂的回收，因为在JVM中垃圾回收器主流也是多线程的，所以很容易导致CPU100%； 2、在遇到内存溢出的问题的时候，一般情况下我们要查看系统哪些对象占用比较多，在实际业务代码中，找到对应的对象，分析对应的类，找到为啥这些对象不能回收的原因，就是通过可达性分析算法，JVM的内存区域，还有就是垃圾回收器的基础。