【java 面试】记录一次“诡异的“CPU 100%问题
2017-12-27 10:40
639 查看
现象:生产服务器偶尔CPU100%,一旦100%,就一直100%,日志长时间不输出任何信息,偶尔会打印一条。
分析流程:
1 开始想,一定是有线程一直运行,所以导致CPU100%。 直接想到了jstack。
使用jstack生成了一个thread dump文件。 jstack -l xxx 没有响应, 最后使用 jstack -F xxx 生成了一个thread dump。 查看生成的dump文件, 里面都是BLOCKED的线程。 这真是颠覆我的理论基础,BLOCKED不会占用太多CPU的啊。。。
经过一夜的思考, 我靠,会不会-F参数导致JAVA所有线程先BLOCKED,然后在生成的Thread dump,在机器上测试了一下,果然就是这样的。你大爷啊,为什么网上没有人说这个问题!!!官网也没有说。
2 使用jstack xxx 生成dump文件
生成的thread dump终于可以网上的格式对应起来了,开心。查找CPU占用高的线程, 一查,靠,都是垃圾回收线程。
好,问题找到了,就是程序中的一个方法一定条件下可以触发一个无限循环,每循环一次,创建了一个对象,所有java堆满了,引起了java垃圾回收。java回收线程不能回收对象释放堆内存,所以垃圾回收线程一直执行,CPU 100%。
3 定位到代码,确实有个在并发条件下,可能出现无限循环的地方,修改了就可以了。
总结:
使用jstack查看线程情况。当是垃圾回收线程一直full gc时, 使用jmap查看那个对象创建的比较多,再结合jstack的线程数据,定位到相关代码。
可以用的下的命令:
参考:http://blog.csdn.net/five3/article/details/28416771
https://www.cnblogs.com/zyhxhx/p/4564953.html
先用top查看占用cpu的进程id
top -H -p 3582
用ps -mp pid -o THREAD,tid,time 打印出该进程下的线程占用cpu情况
jstack [进程] | grep -A 10 [线程的16进制] 打印线程的堆栈信息
printf "%x\n" tid 线程ID转换为16进制格式
查看gc状况:1511274为进程号
jstat -gcnew 1511274 1000 10
jstat -gcutil 1511274 1000 10
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.51 74.23 3.55 23.37 197 46.478 168 628.104 674.582
0.00 0.51 74.76 3.55 23.37 197 46.478 168 628.104 674.582
0.00 0.51 74.90 3.55 23.37 197 46.478 168 628.104 674.582
可以使用jmap来打印堆里的对象个数。
jmap -heap 1511274
java虚拟机
java使用内存 3g -Xmx3g -Xms3g
java新生代内存 1g -Xmn1g
-XX:PermSize=256m -XX:MaxPermSize=256m 持久代256m
/usr/java/default/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Xmx3g -Xms3g -Xmn1g -Xss256k -Dfile.encoding=utf-8 -XX:PermSize=256m -XX:MaxPermSize=256m
-javaagent:/var/fix/fix-bootstrap.jar
-Djava.endorsed.dirs=/opt/apache-tomcat/endorsed
-classpath /opt/apache-tomcat/bin/bootstrap.jar:/opt/apache-tomcat/bin/tomcat-juli.jar
-Dcatalina.base=/var/xxx -Dcatalina.home=/opt/apache-tomcat
-Djava.io.tmpdir=/var/xxx/temp org.apache.catalina.startup.Bootstrap start
分析流程:
1 开始想,一定是有线程一直运行,所以导致CPU100%。 直接想到了jstack。
使用jstack生成了一个thread dump文件。 jstack -l xxx 没有响应, 最后使用 jstack -F xxx 生成了一个thread dump。 查看生成的dump文件, 里面都是BLOCKED的线程。 这真是颠覆我的理论基础,BLOCKED不会占用太多CPU的啊。。。
经过一夜的思考, 我靠,会不会-F参数导致JAVA所有线程先BLOCKED,然后在生成的Thread dump,在机器上测试了一下,果然就是这样的。你大爷啊,为什么网上没有人说这个问题!!!官网也没有说。
2 使用jstack xxx 生成dump文件
生成的thread dump终于可以网上的格式对应起来了,开心。查找CPU占用高的线程, 一查,靠,都是垃圾回收线程。
好,问题找到了,就是程序中的一个方法一定条件下可以触发一个无限循环,每循环一次,创建了一个对象,所有java堆满了,引起了java垃圾回收。java回收线程不能回收对象释放堆内存,所以垃圾回收线程一直执行,CPU 100%。
3 定位到代码,确实有个在并发条件下,可能出现无限循环的地方,修改了就可以了。
总结:
使用jstack查看线程情况。当是垃圾回收线程一直full gc时, 使用jmap查看那个对象创建的比较多,再结合jstack的线程数据,定位到相关代码。
可以用的下的命令:
参考:http://blog.csdn.net/five3/article/details/28416771
https://www.cnblogs.com/zyhxhx/p/4564953.html
先用top查看占用cpu的进程id
top -H -p 3582
用ps -mp pid -o THREAD,tid,time 打印出该进程下的线程占用cpu情况
jstack [进程] | grep -A 10 [线程的16进制] 打印线程的堆栈信息
printf "%x\n" tid 线程ID转换为16进制格式
查看gc状况:1511274为进程号
jstat -gcnew 1511274 1000 10
jstat -gcutil 1511274 1000 10
S0 S1 E O P YGC YGCT FGC FGCT GCT
0.00 0.51 74.23 3.55 23.37 197 46.478 168 628.104 674.582
0.00 0.51 74.76 3.55 23.37 197 46.478 168 628.104 674.582
0.00 0.51 74.90 3.55 23.37 197 46.478 168 628.104 674.582
可以使用jmap来打印堆里的对象个数。
jmap -heap 1511274
java虚拟机
java使用内存 3g -Xmx3g -Xms3g
java新生代内存 1g -Xmn1g
-XX:PermSize=256m -XX:MaxPermSize=256m 持久代256m
/usr/java/default/bin/java -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Xmx3g -Xms3g -Xmn1g -Xss256k -Dfile.encoding=utf-8 -XX:PermSize=256m -XX:MaxPermSize=256m
-javaagent:/var/fix/fix-bootstrap.jar
-Djava.endorsed.dirs=/opt/apache-tomcat/endorsed
-classpath /opt/apache-tomcat/bin/bootstrap.jar:/opt/apache-tomcat/bin/tomcat-juli.jar
-Dcatalina.base=/var/xxx -Dcatalina.home=/opt/apache-tomcat
-Djava.io.tmpdir=/var/xxx/temp org.apache.catalina.startup.Bootstrap start
相关文章推荐
- 记录一次cpu 100%线上问题排查
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- MongoDB的update有关问题(JAVA)——如何一次更新所有的相同记录
- java 程序占CPU100%问题的解决过程
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 记一次java程序CPU占用过高问题排查
- 一次关于Apache 的httpd.exe占用服务器CPU到100%的问题处理心酸历程
- java中HashMap在多线程环境下引起CPU100%的问题解决
- java 一次CPU占用过高问题的排查及解决
- java 程序cpu100%问题
- Java进程CPU100%的问题
- 一次电话Java面试的问题总结(JDK8新特性、哈希冲突、HashMap原理、线程安全、Linux查询命令、Hadoop节点)
- 记录一次java ssm框架下数据回滚问题以及解决方法
- 记录一次服务器CPU 100%的解决过程
- 记一次线上Java程序导致服务器CPU占用率过高的问题排除过程
- 记录一次大对象导致的Java堆内存溢出问题
- java中HashMap在多线程环境下引起CPU100%的问题解决(转)
- 面试随笔——记录一些面试中碰到的问题(初级/中级Java开发)
- 记一次JAVA CPU高问题定位
- 记一次tomcat进程cpu占用过高的问题排查记录