天天看點

1024程式員節這天,我故意寫了個死循環~

導緻CPU100%的原因很多,而程式中出現死循環就是原因之一。然而,并不是每個人在工作中都有機會踩中這個坑。我就是其中一個沒踩過的。人生似乎有些不完整。

是以,我做了一個很重要的決定:在程式中寫一個死循環。看看會發生什麼事情。

當然,不是在生産環境。 我搭建了一個實驗環境來做實驗。隻是這個實驗環境不僅可以用于這個死循環實驗。以下是這個環境的結構圖:

1024程式員節這天,我故意寫了個死循環~

還是老樣子,使用Vagrant + Virtualbox + Ansible自動化搭環境。

我們會寫一個簡單的Spring MVC 應用,然後其中一個接口裡會有死循環代碼:

1024程式員節這天,我故意寫了個死循環~

以下是我自己嘗試找出這個死循環的過程。

一、使用top,檢視是哪個程序的問題

我請求一次:

http://192.168.88.10:9898/web/loop

1024程式員節這天,我故意寫了個死循環~

然後,我打開新視窗,又請求一次

1024程式員節這天,我故意寫了個死循環~

這裡,我好奇CPU沒有到200%。一直在120%和130%之間。P.S. 我一定是某個知識點不牢固,要不,不會有這個疑問。

二、堆空間

因為不涉及JVM堆空間問題,執行 jstat -gcutil 32593 1s 沒看出什麼問題。32593為Java程序ID,1s指1秒抽樣一次。

1024程式員節這天,我故意寫了個死循環~

三、棧

堆沒問題,就看看是哪個線程占用得高。

列出java程序的線程,top -H -p <java 程序pid>

1024程式員節這天,我故意寫了個死循環~

将jvm的棧dump下來 jstack -l <其中一個線程PID> >> stack.log,這裡我選3596。

在日志中,找到相應的線程,我們需要從棧日志中找到相應的線程,但由于棧日志中使用的16進制,但是top中的PID又是10進制。是以,需要手工将10進制的PID轉成16進制。3596的16進制轉是0xe0c

1024程式員節這天,我故意寫了個死循環~

四、小結

從這個解決的方式過程中,我們已經可以看出來一種基本的處理CPU 100%的情況了!希望對大家有所幫助!

歡迎工作一到五年的Java工程師朋友們加入Java填坑之路:860113481

群内提供免費的Java架構學習資料(裡面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用自己每一分每一秒的時間來學習提升自己,不要再用"沒有時間“來掩飾自己思想上的懶惰!趁年輕,使勁拼,給未來的自己一個交代!