快捷導(dǎo)航

Java進(jìn)程cpu頻繁100%問題解決方案

更新時(shí)間：2020年10月12日 09:40:00 作者：imfx

這篇文章主要介紹了Java進(jìn)程cpu頻繁100%問題解決方案,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下

1.在一次周末收到部門的反饋，線上機(jī)器java進(jìn)程的cpu會(huì)頻繁100% 監(jiān)控系統(tǒng)發(fā)了很多報(bào)警郵件，于是登錄跳板機(jī)進(jìn)行排查解決2.使用top命令查看進(jìn)程情況

發(fā)現(xiàn)每隔個(gè)幾秒cpu就達(dá)到100%左右，報(bào)警郵件確實(shí)是誠不欺我，java進(jìn)程有問題

2.于是查看下到底是java進(jìn)程下的哪個(gè)線程造成的cpu頻繁100%

使用top -Hp 25567 查看進(jìn)程下的線程信息

得到線程編號(hào)26250

3.查看該線程的棧信息

printf '%x\n' 26250 獲取26250的16進(jìn)制數(shù)為668a

jstack25567 |grep -A 30668a 得到該線程棧信息

ContainerBackgroundProcessor[StandardEngine[Catalina]] 這是什么任務(wù)，沒見過啊，懵了

繼續(xù)看下面的棧信息有apache.catalina之類的信息(上圖沒有截全)

我們的java服務(wù)是通過war包的形式發(fā)布到tomcat里的，想著是不是因?yàn)閠omcat配置的問題

先網(wǎng)上查一下吧(吃了不了解tomcat底層的虧)

4.根據(jù)網(wǎng)上的資料，有一種說法說是因?yàn)閠omcat的server.xml的reload屬性設(shè)置為了true，那么reload屬性有什么作用呢？

如果這個(gè)屬性設(shè)為true，tomcat服務(wù)器在運(yùn)行狀態(tài)下會(huì)監(jiān)視在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動(dòng)，如果監(jiān)測到有class文件被更新的，服務(wù)器會(huì)自動(dòng)重新加載Web應(yīng)用。在開發(fā)階段將reloadable屬性設(shè)為true，有助于調(diào)試，但這樣用會(huì)加重服務(wù)器運(yùn)行負(fù)荷，建議在Web應(yīng)用的發(fā)存階段將reloadable設(shè)為false。

看到這趕緊和其他節(jié)點(diǎn)的tomcat配置對(duì)比一下，發(fā)現(xiàn)其他節(jié)點(diǎn)的reload都配置為false，只有這一臺(tái)有問題了的設(shè)置為了true。

什么也不說了修改reload為false進(jìn)行重啟，當(dāng)然如果真的不是因?yàn)閞eload配置導(dǎo)致cpu頻繁100%的話，設(shè)置reload為false對(duì)系統(tǒng)也是有好處的。

5.修改reload為false進(jìn)行驗(yàn)證

修改配置重啟后果然沒有再頻繁出現(xiàn)cpu 100%了，至于為什么運(yùn)行這么久監(jiān)控系統(tǒng)才發(fā)通知郵件呢，后來做監(jiān)控的小伙伴說是因?yàn)樗麄兡沁呅畔⒉杉隽藛栴}，沒有發(fā)現(xiàn)。

還有一個(gè)問題，為什么單單只有這一臺(tái)reload為false了，真相只有一個(gè)，項(xiàng)目擴(kuò)展節(jié)點(diǎn)時(shí)，小伙伴使用測試環(huán)境的server.xml配置文件，然后改改端口，war路徑就給發(fā)上去了，這才引出這樣的問題

問題總算解決了。。。。。。。。

以上就是本文的全部內(nèi)容，希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

您可能感興趣的文章: