一、現象 早上九點多又收到了fullGC次數過高的應用監控告警{P1}{故障}JVM Old GC all(#3) full_gc_count >5}{目前值:28}，通過公司使用的監控平台可以觀察到伺服器在這個時間段内确實出現了一些異常情況：
1.負載突然增加
2.fullgc頻率顯著增加，每次時間漸漸增長
3.老年代記憶體使用率增長很快（大量對象直接進入老年帶），可以看到Survivor區一直被打滿（Survivor功效喪失，大量新生代對象不能及時回收越過Survivor直接進入年老代）
二、工具排查
線上日志dump
使用jmap -dump:live,format=b,file=xxx [pid]
工具介紹
市面上提供了很多種工具比如visualVM、JMAT、Jprofile和ha等工具，都可以進行記憶體堆快照檔案分析
1、Jprofile
使用Jprofile需要先将檔案字尾修改為hprof，用Jprofile可以一目了然的看出是大量對象，而且可以看到具體的方法一級classloader資訊
2、ha
使用ha工具需要将dump檔案字尾修改為jvmdump結尾，通過ha.jar工具檢視可以看到大對象數量為66萬多和38萬多，分别占用了300多兆和65多兆堆記憶體
3、JMAT
JMAT也是很好用的工具，建議安裝了eclipse的使用
4、visualVM
這裡不建議用visualVM分析，一個需要設定出展示具體的方法或者對象（沒研究出來），而且預設的記憶體空間比較小，要看大對象需要修改參數 經過試驗後，對于dump檔案分析最好是用Jprofile或者ibm出的ha.jar這個工具或者進行分析效果較好
三、排查結果分析
1、分析結果驗證
根據工具分析結果，對照着監控中的異常可以看到9點11分時候三次long-SQL中查詢傳回了大量對象發現結果和時間都是吻合的，
于是進一步排查代碼
2、代碼排查
排查過程中發現項目中并沒有類似分類服務調用及SQL查詢，是由于依賴的jar包中的方法有查詢資料庫，用的是本地緩存的形式，有個定時器類會從lion配置定時讀取資訊，
緩存過期時間設定的是3600000s，
查到原因這個服務沒有人重新釋出部署過，是以經過四十一天後緩存過期後，再初始化緩存時會重新讀資料庫擷取所有分類和城市的資料，兩次查詢分别擷取了六十多萬分類與城市對應關系的對象，由于數量多，申請堆空間過大，是以大量對象直接進入了老年代，觸發了fullGC
四、解決
這個方法是老的架構元件中方法并且已經很久沒人維護，後續這類商區服務的實作方式需要重構，去掉了本地緩存和直接讀取資料庫的方法，改為分頁調用不是直接查緩存