前言

害。。。

昨天剛寫完一份關(guān)于jvm問(wèn)題排查相關(guān)的博客，今天線上項(xiàng)目就遇到了一個(gè)突發(fā)問(wèn)題。

現(xiàn)象是用戶反映系統(tǒng)非常卡，無(wú)法操作。

然后登錄服務(wù)器查看發(fā)現(xiàn)cpu 一直100%以上。

具體排查步驟：

1，首先top命令查看服務(wù)器cpu等情況：

發(fā)現(xiàn)線上pid 29737的 java應(yīng)用cpu達(dá)到100%

2，top -H -p pid命令查看具體的線程情況

top -H -p 29373

輸入上述命令，然后按H顯示cpu最高排名的線程。可以看到pid 30013的線程cpu 100%且一直未釋放。

3.將線程的pid轉(zhuǎn)為16進(jìn)制

printf "%x\n" 30013

30013做16進(jìn)制轉(zhuǎn)換為753d

4.使用jvm工具jstack打印該進(jìn)程的堆棧信息

使用該命令打印堆棧信息的后50行

jstack 29737 |grep -A 50 753d 

然后就可以具體看到具體的出問(wèn)題的是哪部分代碼了，然后檢查更改即可。(我們的是代碼中出現(xiàn)死循環(huán))

注意問(wèn)題：

可能會(huì)出現(xiàn)以下報(bào)錯(cuò)：

xxxx: 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

有兩個(gè)可能：

1.jstack后面的進(jìn)程pid不對(duì)，或者16進(jìn)制的數(shù)不對(duì)。

需要注意jstack后面是jps的java進(jìn)程id。

2.執(zhí)行該命令的用戶必須和java應(yīng)用所屬的用戶一致。

常見(jiàn)的cpu飆升原因

程序中存在死循環(huán)或者長(zhǎng)時(shí)間占用 CPU 的操作。比如，不合理的遞歸操作、循環(huán)操作等等。

程序中存在大量的計(jì)算操作，例如復(fù)雜的算法、大量的數(shù)值計(jì)算等等。

程序中存在大量的 IO 操作，例如讀寫文件、網(wǎng)絡(luò)通信等等。

程序中存在大量的線程創(chuàng)建和銷毀操作，以及線程間的競(jìng)爭(zhēng)和同步操作。

程序中存在內(nèi)存泄漏或者內(nèi)存溢出，導(dǎo)致 JVM 不斷進(jìn)行垃圾回收。

程序中存在大量的數(shù)據(jù)庫(kù)操作，導(dǎo)致數(shù)據(jù)庫(kù)連接池的耗盡和數(shù)據(jù)庫(kù)負(fù)載過(guò)高。

針對(duì)這些問(wèn)題，需要具體情況具體分析，采取相應(yīng)的優(yōu)化措施，例如修改代碼邏輯、優(yōu)化算法、降低 IO 操作頻率、減少線程創(chuàng)建和銷毀、增加 JVM 內(nèi)存等等。

總結(jié)

到此這篇關(guān)于java應(yīng)用cpu飆升(超過(guò)100%)故障排查步驟的文章就介紹到這了,更多相關(guān)java應(yīng)用cpu飆升故障內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論