原文链接： https://blog.csdn.net/manzhizhen/article/details/79333676
老司机在定位和解决问题时都有着自己的一套方法论，总不能老踩一些重复的坑是吧。老司机一般多少都遇到过服务器cpu飙高的问题，定位问题的方法网上文章多如牛毛，现这里再总结一下，对于混部多个Java应用的服务器，我们一般会通过如下步骤来定位该问题：
找到cpu占比高的Java进程ID，通过这一步就知道是哪个Java应用出了问题。
然后再找到该Java进程中哪些线程占用cpu时间比较高，有时候步骤2和步骤1可以合为一个步骤。
jstack -l 该Java进程到某个文件(比如/tmp/jstack.dump)。
再将步骤2得到的线程ID由10进制转换成16进制，去jstack.dump文件中看这些线程到底是执行了哪些Java代码，从而可以找出问题。
先来看看步骤1，定位cpu占比高的Java进程比较简单，可以直接通过top命令或ps命令，但由于top命令比较简单，不像ps命令有过多的参数，所以大多数会优先使用top命令。找到出问题的Java进程后，就知道是哪个应用出问题了，这时候该应用的Owner就应该通知到位了。
步骤2是进一步定位到出问题的线程，常用的有如下几个方法：
top命令 + （shift+H）实时显示线程用肉眼看！
top -Hp $pid 实时用肉眼来看！
ps -mp $pid -o THREAD,tid,time 直接看线程快照结果。
ps H -eo user,pid,tid,%cpu --sort=-%cpu | grep $pid 直接看线程快照结果。
有时候为了简单，可以直接定位到出问题的线程，这是习惯问题，这里不做过多讨论。
不管怎样，都逃不过步骤3，即jstack进程到一个临时文件。
步骤4主要是分析问题了，有个稍微“恶心”的是jstack文件中的线程ID用的是16进制，所以我们得把步骤2得来的线程ID转一下。
由于上面4个步骤说长不长，说短也不短，特别是在定位线上问题时心里难免紧张，命令用的不熟的话，容易造成定位问题时间过长。
于是网上老司机就将如上4个步骤合成在一个脚本中，希望通过一个脚本就搞定，作者在网上也找了一些，有的写的很简单，但就是执行起来报错；有的写的很专业，功能齐全，文档也写的比较好，但过于复杂，修改起来难度高，不太敢在线上环境使用。
于是作者又花了点时间重复造了一个*，写了一个只有35行的Shell脚本，并"厚颜无耻"的写成了本篇博文，作者的思路其实很简单，将前3个步骤的结果直接写入jstack后的文件中，一个jstack后的文件即可完成问题定位！
先来看看使用该脚本生成dump文件内容：
有了上图的文件，就可以直接在文件中找cpu占比为94.3的0x65c6等线程的对于代码了！是不是很方便？为了方便多次采样，该脚本生成的文件名为pid-$pid-时间.jstack，默认放在/tmp目录下，比如如果是ID为12345的Java进程的cpu占比最高，那么通过该脚本生成的文件有可能是/tmp/pid-12345-20180217T22:51:03.jstack。
因为脚本做的事情不多，也很简单，只有35行，你看到哪里不爽，可以直接修改，下面直接附上该shell脚本代码：
#!/bin/bash
# 入参只有一个，即目标java的pid，如果没有，则默认找cpu最高的java进程
if [ -z "$1" ]; then
### 1.先找到消耗cpu最高的Java进程 ###
pid=`ps -eo pid,%cpu,cmd --sort=-%cpu | grep java | grep -v grep | head -1 | awk 'END{print $1}' `
if [ "$pid" = "" ]; then
echo "无Java进程，退出。"
exit
fi
else
pid=$1
fi
### 2.生成dump后的文件名 ###
curTime=$(date +%Y%m%dT%H:%M:%S)
# jstack后的文件会加上时间，便于对一个进程dump多次
dumpFilePath="/tmp/pid-$pid-$curTime.jstack"
echo -e "cpu最高的java进程: "`jps | grep $pid`"\n" > $dumpFilePath
### 3.取到该进程的所有线程及其cpu(只显示cpu大于0.0的线程) ###
echo -e "进程内线程cpu占比如下（不显示cpu占比为0的线程）:\n" >> $dumpFilePath
ps H -eo pid,tid,%cpu --sort=-%cpu | grep $pid | awk '$3 > 0.0 {totalCpu+=$3; printf("nid=0x%x, cpu=%s\n", $2, $3) >> "'$dumpFilePath'"}
END{printf("cpu总占比:%s\n\n", totalCpu) >> "'$dumpFilePath'"}'
### 4.dump该进程 ###
echo -e "如下是原生jstack后的结果:\n" >> $dumpFilePath
jstack -l $pid >> $dumpFilePath
echo "dump成功，请前往查看(文件名包含时间，为了采集更准确，可以多执行几次该命令):" $dumpFilePath
exit
记住，执行该脚本你得拥有使用jps、jstack等命令的权限。
使用方法（假设将上述脚本保存为javacpu.sh文件）
方法1：直接让脚本来查找cpu占比最高Java进程并在/tmp目录下生成dump文件，直接sh ./javacpu.sh即可。
方法2：直接使用该脚本在/tmp目录下形成某个Java进程(比如ID为123456)的dump文件，可以 sh ./javacpu.sh 123456。
先解决问题再去定位问题，这是线上事故处理的第一原则，如果遇到线上cpu飙高问题，先多次执行该脚本以便留下“犯罪”现场，然后再重启或回滚服务，后面再去分析该脚本生成的文件来定位问题。
本文很短，也没有阐述高深的技术知识，但想和各位分享一句从老大那听来的一句话：将小事做到极致，就是创新。工作如此，人生也如此。
---------------------
作者：大步流星Java
来源：CSDN
原文：https://blog.csdn.net/manzhizhen/article/details/79333676
版权声明：本文为博主原创文章，转载请附上博文链接！