1.在一次周末收到部門的反饋，線上機器java進程的cpu會頻繁100% 監控系統發了很多報警郵件，於是登錄跳板機進行排查解決
2.使用top命令查看進程情況
發現每隔個幾秒cpu就達到100%左右，報警郵件確實是誠不欺我，java進程有問題
2.於是查看下到底是java進程下的哪個線程造成的cpu頻繁100%
使用top -Hp 25567 查看進程下的線程信息
得到線程編號26250
3.查看該線程的棧信息
printf '%x\n' 26250 獲取26250的16進制數為668a
jstack 25567 |grep -A 30 668a 得到該線程棧信息
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路徑就給發上去了，這才引出這樣的問題
問題總算解決了。。。。。。。。