臨近月底，用戶量上來，發現業務進程頻繁從Eureka上掉下來，觀察后發現掉下來前進程CPU一直占用比較高。
按
《Java進程CPU使用率高排查》方法查看堆棧信息，發現有個方法很可疑，發給開發人員查看，覺得表數據量太大，查詢沒有走索引，新建索引后，感覺情況有好轉。
排查步驟如下：
1.使用top 定位到占用CPU高的進程PID
top
2.獲取線程信息，並找到占用CPU高的線程
ps -mp pid -o THREAD,tid,time | sort -rn
3.將需要的線程ID轉換為16進制格式
printf "%x\n" tid
4.打印線程的堆棧信息
jstack pid |grep tid -A 30
同時發現數據庫連接有報“Connection reset”的異常，一時也發現不了問題，將dbcp2連接池換成durid。
通過durid的spring監控發現（果真非常強大），還是同樣的方法讀取行數非常大。
發現《
記一次線上Java程序導致服務器CPU占用率過高的問題排除過程》問題情況非常相似，因為在之前用jstack查看時，就是GC占用CPU非常高。
再仔細看代碼，發現某種情況下，確實會讀取全量表數據。
優化代碼后，問題解決。