1. 周二新需求提測之后，運行到晚上，收到告警短信，生產環境CPU負載過高，先解決問題再排查，運維擴容，有問題機器下線重啟上線，CPU使用率正常，服務正常響應。
2. 開始排查問題，把預留的一台有問題的機器用於排查問題，
第一步，看相關的日志，沒有明顯的異常。然后top 命令查看cpu資源使用情況，jps -lm找到對應java進程號9021之后，top -H -p9021 看到線程占用情況，cpu利用率93%
記錄使用率高的具體的線程id： 9023，9024，9027，9029 在linux中，線程就是輕量級進程
然后通過jstack 查看線程堆棧信息，jstack 9021 > jstack_9021.txt ， 然后把十進制的9023，9024，9027，9029轉成十六進制（0x233f，0x2340, 0x2343, 0x2345）
最后，通過 cat jstack_9021.txt | grep -C 20 0x233f 命令找到了具體的線程信息, 發現把cpu打滿的是GC 線程，然后jmap 先總體看內存使用狀況，Xmx配置挺高，不存在內存不夠，
然后jstat -gcutil 9021 3000 20 查看GC回收情況，每間隔3000ms打印一次，打印20次，發現Eden區和Old區都耗盡了，FullGc非常慢，耗時很長，基本可以確定發生了內存泄漏。
jmap -histo 9021 打印內存占用情況，發現主要是新引入第三方RSA包里SignContent對象很大，因為這個對象包含了圖片的Base64 decode字節和PDF文件的Base64編碼字節。放在集合里，請求結束沒有釋放導致的。