java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > java进程cpu

Java进程cpu占用过高问题解决

作者:陈晓呆

这篇文章主要介绍了Java进程cpu占用过高问题解决,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下

cpu是时分(time division)的,操作系统里有很多线程,每个线程的运行时间由cpu决定,cpu会分给每个线程一个时间片,时间片是一个很短的时间长度,如果在时间片内,线程一直占有,则是100%;我们应该意识到,cpu运行速度很快(主频非常高),除非密集型耗费cpu的运算,其它类型任务都会在小于时间片的时间内结束。

产生CPU100%的原因:

某一程序一直占用CPU是导致CPU100%的原因,大概有以下几种情况:

1、Java 内存不够或溢出导致GC overhead问题, GC overhead 导致的CPU 100%问题;

2、死循环问题. 如常见的HashMap被多个线程并发使用导致的死循环, 或者死循环;

3、某些操作一直占用CPU

第一步:使用top命令,查看占用cpu的进程

[root@sdfsdfseZ codeimage]# top

第二步:ps -ef | grep java 或jps命令,找出服务器的所有java进程

第三步:找出CPU耗用最厉害的进程pid

第四步:查找出具体占用cpu利用率最厉害的线程号,top -H -p pid 。然后按下shift+p,跳出CPU监控
当前线程号为:1747

第五步:将获取到的线程号转换成16进制

因为java线程栈文件中的线程id是十六进制,需要将线程id从十进制转为十六进制。十进制 转十六进制的命令如下:

结果为:

第六步:导出线程栈

将具体的占用CPU过高的java进程的线程栈导出,导出命令如下:

pid.tdump文件后缀名随意,通常以tdump结尾。

[root@sdfsdfsdeZ codeimage]# jstack 1747 > tmp/1747.tdump

可能会抛出异常;

1747: Unable to open socket file: target process not responding or HotSpot VM not loaded
The -F option can be used when the target process is not responding

原因分析

jvm运行时会生成一个目录hsperfdata_$USER($USER是启动java进程的用户),在linux中默认是/tmp,目录下会有些pid文件,存放jvm进程信息,而jmap,jstack等工具会读取/tmp/hsperfdata_$USER下的pid文件获取连接信息.

检查了/tmp/hsperfdata_root目,,但在$TOMCAT_HOME目录中的temp目录中有对应的文件.

解决办法

使用

[root@iZ2zeab8t820b5ywp0rkfeZ bin]# jstack 1706 > /tmp/hsperfdata_root/1706.tdump

第七步:导出堆

[root@sddsdfsaZ bin]# jstat -gcutil 1706

第八步:jvisualvm分析快照使用JAVA_HOME/bin/jvisualvm.exe,载入快照

文件----->载入—>文件类型(Dump)

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文