1、定位 CPU 最高的 进程

Htop 可以点击 CPU 选项 会自动进行大小排序

Top 命令

shift + M 按照 memory 倒序排序

Shift + P 按照 CPU 倒序排序

2、使用top -Hp 查看进程中所有线程的运行信息

top -Hp 21622

继续 shift + P 找出 打满CPU的 Max_thread_pid

3、使用printf %x Max_thread_pid 转换成十六进制

4、通过 jstack查看进程栈信息 定位 吃CPU线程信息

jstack 21622 | grep -A 30 5487

Gang worker为CMS垃圾收集器的处理线程，此处对老年代进行回收。定位到垃圾收集器的问题

jstack 21622 | grep -A 30 5488

5、jstat 查看 进程 gc 情况

jstat -gccause 21622 2000

当前截图 是重启后的截图现场 目前来看是正常的

未重启的时候 该命令 隔两秒 FGC 就会+1 FGC 的数值 大约是 20000多次

产生了频繁Full GC，进行了接近万数量级别的Full GC，且在该命令执行的20s内，Full GC次数就增加了3次。为了更好的查明原因，先使用命令jinfo -flags 21622查看JAVA启动选项参数，结果如下：

期间我恢复之前默认的jvm参数 重启了一下 进程号切换为 27849

老年代内存 占80% 青年代 占 20%

使用命令jmap -histo:live 27849查看一下老年代的存活对象情况

并且设置了选项CMSInitiatingOccupancyFraction的值为70。也就是说，由于老年代占用量为80%，超过了进行GC的阈值70%，所以CMS进行老年代回收，但老年代的对象仍处于生存期，并不是垃圾而不能回收。由此进入死循环，不断尝试回收，但却回收不到空间，由此消耗大量CPU资源。

和我第一次排查的数据显示 基本满足 问题的根本原因 就在于此

-XX:NewRatio 默认是 2

-XX:CMSInitiatingOccupancyFraction 默认是 -1

6、命令行集锦

1、top
    shift + M  内存 排序
    shift + P  CPU 排序

2、top -Hp java_thread_id


3、printf %x max_cpu_thread_id  

4、jstack 21622 | grep -A 30 5487 打印 吃CPU 线程 栈信息

5、jstat -gccause 21622 2000  两秒间隔 输出 21622 进程 gc 信息

6、jinfo -flags 21622  查看 21622 启动 jvm 参数

7、jmap -histo:live 21622  查看一下老年代的存活对象情况