原因及解決辦法：一是病毒所致。下載安裝殺毒軟件，對硬盤特別是系統盤進行反覆查殺，徹底查殺隱藏在系統中的各種病毒。並在今後使用電安，安裝各種應用軟件前做好查殺病毒事項，防止病毒再次入侵。二是執行項目過多，特別是執行大型遊戲時，導致cpu壓力過大，導致難以執行甚至死機，這種情況下我們要關閉不必要的程序，減輕cpu的壓力。三是系統垃圾過多。日常使用過程中，要保持良好的用機習慣，經常對系統盤進行垃圾清理，保證系統正常執行。
2、第二步 執行top -Hp 1，檢視到進程1下面的pid是8，9，10，11這四個線程的cpu佔用比較異常
對應java程序裏的tid是0x8 0x9 0xa 0xb。
3、第三步執行jstack 1 > 獲取到日誌檔案，查到剛好是垃圾回收的幾個線程
4、第四步再執行jstat -gcutil 1 2000
發現FGC很頻繁，而且有沒次fgc的效率不高，就算回收了還是暫用97、98%，說明有大量的老年代對象沒有被回收
5、第五步，是什麼原因導致老年代對象沒有被回收呢，首先我們先執行java -XX:+PrintCommandLineFlags -version
newRatio 等於2，老年代，佔比2/3，4/3g * 98% = 1.306g的老年代堆內存一直不能被回收。
6、第六步，執行jmap -dump:format=b，file= 1，生成dump檔案，使用visualVm工具開啟dump檔案
分析發現有很多boundSql佔用了大量的內存，並且不能被釋放，這條sql是updateBatchById，查詢數據庫
這條sql一直被佔用，並且不會被釋放。查閱代碼，發現有一條批量更新語句，使用case id when then 的語法，這條批量更新語句更新大概2w行數據，導致數據庫SQL語句執行緩慢，e其實是固定的，沒有必要這樣寫sql。後修改SQL 爲updat a set a.c = d where e = xxx，重新部署，執行一段時間，服務器的cpu一直正常。
