一、说明
1、正式环境，cpu飙升，需要排查想原因
2、正式环境： CentOS8 + jdk8 + nginx + java服务
二、过程
1、查看cpu占用
1）命令
top c
说明1： 从高到低，显示cpu占用，并标识应用
~~
2、查看pid的子线程
1）命令
top -Hp ${pid}
说明： 查询的子线程，即tid，线程ID
~~
3、将tid转为16进制
1）命令
printf "%x \n" ${tid}
说明： 后续命令要用到
4、打印堆栈信息
1）命令
jstack ${pid} | grep ${16进制tip} -A 30
说明1： pid是程序id；tid是线程id（16进制的）
说明2： -A 30，即打印30行；也可以改成300
说明3： jstack如果找不到的话，使用绝对路径，在$JAVA_HOME/bin
说明4： 可以打印处理
echo $JAVA_HOME
示例：
/opt/jdk/jdk1.8.0_231/bin/jstack 584867 | grep 8ed00 -A 30
说明5：一般把结果导入到文件，然后下载到windows环境查看
/opt/jdk/jdk1.8.0_231/bin/jstack 584867 | grep 8ed00 -A 30 > jstack.log
说明6： 下载并查看排查就不赘述了
~~
5、备份其他命令
1）jmap -heap ${pid}：输出堆内存设置和使用情况（JDK11使用jhsdb jmap --heap --pid pid）
jmap -heap
2）jinfo -flags ${pid}：查看运行时进程参数与JVM参数
/opt/jdk/jdk1.8.0_231/bin/jinfo -flags
3）jmap -histo ${pid}：输出heap的直方图，包括类名，对象数量，对象占用大小
jmap -histo
说明： 建议用绝对路径，当系统装了多个jdk版本的话，可能提示版本不一致的问题
4）查看系统支持的最大线程数
cat /proc/sys/kernel/threads-max
5）jvm系统监控软件
jvisualvm
下载链接
https://visualvm.github.io/index.html
~~
6、cpu飙升原因分析
1）事情的经过
a> 项目是老项目（springboot），是war包，用的tomcat独立容器，版本是： apache-tomcat-8.5.64；什么问题呢，分析得出结论是连接没有释放，tomcat连接线程处于WAITING状态（假死），导致cpu居高不下，重启后恢复
b> 改了项目配置，用springboot内嵌tomcat，版本是： 9.0.39，然后还是发现cpu居高不下，找了好多blog，有个文章说是资源泄露了、建议用线程池，就往这个方向靠；然后全局搜了tomcat配置，确定下是否用了线程池；然后发现，没有用到；然后yml增加上配置
tomcat:
# tomcat的URI编码
uri-encoding: UTF-8
# 连接数满后的排队数，默认为100
accept-count: 5000
threads:
# tomcat最大线程数，默认为200
max: 5000
# Tomcat启动初始化的线程数，默认值10
min-spare: 100
重启后，cpu降下来了，低于40%（姑且认定为配置有效）
c> 但是，监控了一段时间，发现cpu还会飙到40%；执行了上面的堆栈信息，WAITING已经没有了，
标签：java,tomcat,top,30,pid,线程,jvm,jmap,cpu From： https://blog.51cto.com/u_15891242/5885723改成了这个：
没有看错，是业务代码，业务代码导致cpu飙升，可以断定是这块业务有计算量。
d> 看了业务代码，这块用到一个算法；然后加了些日志，打印下耗时时间。结果发现，的确是算法涉及到计算（计算参数越多、越耗时，目前发现一次计算最大耗时2分钟）。算法计算这块，不属于服务异常了，但是依然是个潜在的风险点，还需要想办法规避掉；要么改算法，要么扩容cpu（4核的，的确不够看），要么用其他方案。
e> 大致上是这么个情况。
~~
