您现在的位置是:首页 > 文章详情

1024这天,我故意写了个死循环~

日期:2018-10-23点击:359

导致CPU100%的原因很多,而程序中出现死循环就是原因之一。然而,并不是每个人在工作中都有机会踩中这个坑。我就是其中一个没踩过的。人生似乎有些不完整。

所以,我做了一个很重要的决定:在程序中写一个死循环。看看会发生什么事情。

当然,不是在生产环境。 我搭建了一个实验环境来做实验。只是这个实验环境不仅可以用于这个死循环实验。以下是这个环境的结构图:

252cb31a541c27f9bc0a4fdc68490409251c6ac8

还是老样子,使用Vagrant + Virtualbox + Ansible自动化搭环境。

我们会写一个简单的Spring MVC 应用,然后其中一个接口里会有死循环代码:

eec0636349458ccc39808b10f983e262fbf68d7f

以下是我自己尝试找出这个死循环的过程。

一、使用top,查看是哪个进程的问题

我请求一次:

http://192.168.88.10:9898/web/loop

65b685c4f00327821015a8f95a7abdd5ab9c7161

然后,我打开新窗口,又请求一次

d43fd03d51e1c8a5890b4450e3bbbde2217c8fc7

这里,我好奇CPU没有到200%。一直在120%和130%之间。P.S. 我一定是某个知识点不牢固,要不,不会有这个疑问。

二、堆空间

因为不涉及JVM堆空间问题,执行 jstat -gcutil 32593 1s 没看出什么问题。32593为Java进程ID,1s指1秒抽样一次。

8c948ee099b377ffa9e98b8f749e68cd93102068

三、栈

堆没问题,就看看是哪个线程占用得高。

列出java进程的线程,top -H -p <java 进程pid>

f21e524c9f304ab51ed0089932bb5936d4fa1187

将jvm的栈dump下来 jstack -l <其中一个线程PID> >> stack.log,这里我选3596。

在日志中,找到相应的线程,我们需要从栈日志中找到相应的线程,但由于栈日志中使用的16进制,但是top中的PID又是10进制。所以,需要手工将10进制的PID转成16进制。3596的16进制转是0xe0c

f027526810f1f282d1d659777cb92ad0bdc37a37

四、小结

从这个解决的方式过程中,我们已经可以看出来一种基本的处理CPU 100%的情况了!希望对大家有所帮助!


原文发布时间为:2018-10-24
本文作者:翟志军
本文来自云栖社区合作伙伴“ Java后端技术”,了解相关信息可以关注“ Java后端技术”。
原文链接:https://yq.aliyun.com/articles/657117
关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。

文章评论

共有0条评论来说两句吧...

文章二维码

扫描即可查看该文章

点击排行

推荐阅读

最新文章