線上FullGC頻繁，old區(qū)下不去

問題：
線上一個服務，跑了一個月挺正常的，這兩天突然頻繁FULLGC報警，因為fgc頻繁會影響服務使用，而且報警太頻繁了我就先重啟系統(tǒng)了。下面是我自己排查過程的一些記錄截圖：
首先我先看了下系統(tǒng)內(nèi)存和負載概況：

然后看一下我應用啟動參數(shù)：

重要的是JAVA_OPS, 文字放一下：-Xms4g -Xmx4g -Xmn2g -Xss1024K -XX:MetaspaceSize=64m -XX:MaxMetaspaceSize=256m -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseCMSCompactAtFullCollection -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:CMSInitiatingOccupancyFraction=80 -XX:+PrintGCDetails -XX:+PrintGCDateStamps

jstat -gc 看了一下（因為并沒有打印gc日志到文件中，所以只能通過這種方式觀察了）

可以看到最后倒數(shù)第三列是FGC的次數(shù)，幾秒鐘之內(nèi)確實長得比較快，按理說fgc應該一天都不會出現(xiàn)幾次的。第八列是老年代使用的情況（截圖的時候已經(jīng)過了一段時間了實際上1400000 多的時候FGC就開始漲了），F(xiàn)GC次數(shù)上漲而已使用空間不下降，說明FGC并沒有有效的釋放內(nèi)存。

map -heap 的狀態(tài)：

網(wǎng)上說對象太多，看看都是什么對象太大了，于是我又jmap -histo了一下，發(fā)現(xiàn)[C占得比重最大（這個是字符數(shù)組吧，其實就應該是字符串吧）：

這個服務是操作elasticsearch的rpc服務，（不是dubbo，公司內(nèi)部的一個rpc框架），調(diào)用方通過我的接口對es增刪改查。我將返回的數(shù)據(jù)通過fastjson解析最后返回給調(diào)用方。代碼里沒有靜態(tài)集合（類似static Map<String,Object> 這種對象）,qps高峰期達到370/s,晚上低峰期也就30-50/s.之前出現(xiàn)過一次高頻fullgc，我去掉了一些多余的日志輸出，結(jié)果還是出來了。

求解決辦法，還要從哪里著手排查呢

回答

編輯回答

愛是癌

sf上難得的好問題，你貼的信息還不夠全，在發(fā)生full gc的時候，登上機器用top -H找到最忙的線程pid，再用jstack dump當時的線程快照，把這個貼上來，還有開啟gc.log會有更多的現(xiàn)場信息，看看具體是哪塊不夠觸發(fā)了fullgc。單純的看你描述的問題來看，有點像某些邏輯存在內(nèi)存泄露，就算fullgc了也趕不上內(nèi)存增長的速度。

2017年7月3日 07:49

編輯回答

萌吟

對了順便說一下，gc日志我這個應用沒打，但是看別的應用是有的，我就看了一下發(fā)現(xiàn)他們的應用通過jstat -gc 觀察到 FGC這一列也出現(xiàn)了幾百次了（跑了幾個月的），但是gc.log日志里面絲毫沒有fullgc的字樣，只有一些 cms-current-sweep-start 這種，有點糊涂，F(xiàn)GC這一列到底是不是代表著fullgc次數(shù)呢？

2017年7月29日 22:45

編輯回答