引用：
https://blog.csdn.net/qq_37515544/article/details/123921604
https://blog.csdn.net/yujing1314/article/details/114524668
一、定位哪个程序占用的CPU较高
linux命令：top
二、jstack使用
2.1 栈信息输出
命令格式：jstack pid > 文件信息
eg：jstack 5115 > a.txt
2.2、线程ID转为16进制,访问转换地址
将子线程TID的5158做进制转换为16进制：1426
2.3、通过16进制的线程ID在栈信息中查找定位代码行
三、jmap 工具
3.1 生成 hprof文件
以下两个命令都可生成hprof文件
命令1：jmap -dump:file=/data/dump/jvm_en.hprof 20176
命令2：jmap -dump:live,format=b,file=m.hprof PID
四、MAT工具（linux）
在线解析dump文件，然后会生成三个zip文件
4.1 下载工具
http://www.eclipse.org/mat/downloads.php
4.2 查看服务器版本
在linux服务器执行命令 uname –m查看版本
下载完成后直接 上传MAT到服务器后解压
4.3 配置MAT
修改MAT的内存大小， 注意这个大小要根据你dump文件大小来的，如果dump文件是5GB那么 这里最好配>5GB 否则会报MAT内存不足的异常
4.4 执行分析
执行命令
./ParseHeapDump.sh m.hprof org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components
注释：
m.hprof：就是jvm的dump文件。
在mat目录下会生成3份.zip结尾的报告和一些m.相关的文件，将生成的m.hprof相关的文件都下载到windows本地磁盘。
以上命令执行完成后会在 m.info所在目录中生成三个文件,下载下来本地浏览器打开
jmap_Leak_Suspects.zip
jmap_System_Overview.zip
jmap_Top_Components.zip
4.5 下载后在浏览器查看分析报告
查看Class Histogram一项
发现其中一个类对象占用了7个G，这里的Heap单位都是Byte，自行换算。
Shallow Heap 既对象本身的大小
Retained Heap 对象自身加起直接或间接引用的大小
也可以使用使用eclipse的mat工具：
Eclipse需要按照mat工具，安装步骤可以百度，或者参考
https://jingyan.baidu.com/article/cb5d61053562ed005c2fe022.html
如果直接打开dump文件还是会内存溢出，所以可以使用eclipse打开分析报告即可。
4.6 注意：
执行命令后，可能会出现版本问题
下载mat对应jdk的版本解决此问题。
此处使用的是：jdk1.8、mat使用的是 MemoryAnalyzer-1.10.0.20200225-linux.gtk.x86_64.zip
五、jvisualvm工具（jdk自带）
如果dump比较小可以直接下载下来同步哦此工具查看
下载dump后，载入到此工具就可以查看了
六、CPU飙升问题产生的背景
1、代码中存在死循环
2、定时任务跑批量
3、tomcat高并发项目的时候，所有线程都处在运行状态，消耗CPU资源
4、Redis的端口6379被注入挖矿程序
5、分布式锁的重试机制
a、乐观锁：能够保证用户线程一直在用户态，缺点是消耗CPU的资源
b、CAS自旋锁
七、如何避免CPU飙升问题
1、检查代码的死循环情况
2、定时任务项目要喝业务逻辑项目分开部署
a、降低业务逻辑项目CPU资源消耗
b、更好实现定时分片执行
3、接口比较耗时的代码不要写成同步，改为使用mq
4、对服务器接口实现限流、熔断和降级
5、端口号不要随意放开，要结合nginx、LVS等
6、写自旋锁一定要控制死循环次数
tips:预警系统很重要
部分内容，来源于其他大神，感谢各位大神的指点。
————————————————
版权声明：本文为CSDN博主「麦兜*」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_37515544/article/details/123921604