1.在一次周末收到部門的反饋，線上機器java進程的cpu會頻繁100% 監控系統發了很多報警郵件，于是登錄跳板機進行排查解決2.使用top命令查看進程情況

發現每隔個幾秒cpu就達到100%左右，報警郵件確實是誠不欺我，java進程有問題

2.于是查看下到底是java進程下的哪個線程造成的cpu頻繁100%

使用top -Hp 25567 查看進程下的線程信息

得到線程編號26250

3.查看該線程的棧信息

printf ’%xn’ 26250 獲取26250的16進制數為668a

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

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

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

我們的java服務是通過war包的形式發布到tomcat里的，想著是不是因為tomcat配置的問題

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

4.根據網上的資料，有一種說法說是因為tomcat的server.xml的reload屬性設置為了true，那么reload屬性有什么作用呢？

如果這個屬性設為true，tomcat服務器在運行狀態下會監視在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動，如果監測到有class文件被更新的，服務器會自動重新加載Web應用。在開發階段將reloadable屬性設為true，有助于調試，但這樣用會加重服務器運行負荷，建議在Web應用的發存階段將reloadable設為false。

看到這趕緊和其他節點的tomcat配置對比一下，發現其他節點的reload都配置為false，只有這一臺有問題了的設置為了true。

什么也不說了修改reload為false進行重啟，當然如果真的不是因為reload配置導致cpu頻繁100%的話，設置reload為false對系統也是有好處的。

5.修改reload為false進行驗證

修改配置重啟后果然沒有再頻繁出現cpu 100%了，至于為什么運行這么久監控系統才發通知郵件呢，后來做監控的小伙伴說是因為他們那邊信息采集出了問題，沒有發現。

還有一個問題，為什么單單只有這一臺reload為false了，真相只有一個，項目擴展節點時，小伙伴使用測試環境的server.xml配置文件，然后改改端口，war路徑就給發上去了，這才引出這樣的問題

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

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支持好吧啦網。