今天跟大家聊聊JVM CPU资源过多的故障排除过程，可能很多人都不太了解。为了让你更好地理解，边肖为你总结了以下内容，希望你能从这篇文章中有所收获。
早上一个在线应用中的一个JVM的CPU比例突然飙升到192%，一直没有降下来，导致监控一直报警。我很久没有处理这个问题了。现在我将总结并记录故障排除步骤。(以下图片并非网上问题截图，涉及公司业务。)
1.通过top命令检查当前机器的CPU使用情况。
这时候发现，如果Java的进程占用太多，又不能一直下来，那就要检查是什么线程造成的高比例。以图中流程为例。如果发现PID为31357的Java进程的CPU比率总是很高，记录下它的PID。
2.检查Java进程中的线程占用情况。
顶部-H -p31357
说明：-H表示显示线程，-p表示指定进程。
可以看到CPU占用了大量的线程，记下它们的PID。假设31357的CPU始终是50%。
3.通过jstack命令获取资源占用异常的线程栈，可以临时保存在文件中查看。
jstack 31357 jstack.31357.log
您可以看到上面指定线程的堆栈信息。
如果想查看线程中锁的其他信息，可以添加一个-l参数。
4.上述方法用于工艺正常时的堆栈打印。今天，jstack -l命令没有响应。估计是CPU一直站着，无法执行正常命令。根据提示【目标进程不响应时可以使用-f选项】，只能放大。
jstack-F“PID”jstack。“PID”。文本文件（textfile）
吐槽的实际日志结果如下：
发现很多线程被阻塞，有用的结果在这里：
显然，线程19576一直在运行，一直在执行EXCEL导出的相关方法。这就是问题所在。接下来的任务是检查这个地方的代码逻辑。
Jstack命令格式：
jstack [选项] pid
参数：
-f jstack [-l]在PID无法响应时强制打印堆栈。
-长长的名单。打印关于锁的附加信息，例如属于java.util.concurrent的可拥有的同步器列表.
-m混合模式输出(包括java和本地c/c片段)堆栈。
java应用程序的进程号。
记得没错的话这几个参数是互斥的，不能联合使用。
5.搜索数据后发现，用jps命令检查java进程的pid更实用：
命令格式
jps [选项] [ hostid ]
参数描述
-m输出传递给main方法的参数，如果是嵌入式JVM，输出为null。
-l输出应用主类的完整包名或应用JAR文件的完整路径。
-v输出传递给JVM的参数。
这三个参数一起显示了更详细的信息：
发现JMX的远程端口是在这些Java进程的启动参数中打开的。正常情况下，通过jconsole远程连接可以看到JVM的日常参数。例如，本地访问上图中的pay.war流程：
看完以上，你对JVM的CPU资源占用问题的故障排除过程有进一步的了解吗？如果您想了解更多知识或相关内容，请关注行业资讯频道，感谢您的支持。
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/44218.html