记录一段关于ygc的优化经历

有一天正在上班，突然收到线上系统告警：容器重新初始化，感觉登录系统看了看，原来是gc造成了8s的停顿，如图所示：
备注: 我们系统使用6g的内存，新老带占比是1:1，垃圾收集算法是使用ParNew + cms算法
这一看gc耗费了这么长时间，肯定哪里有问题啊。赶紧去查了查日志：

promotion failed 的日志浮出了水面，这个日志表示ygc的时候，survivor放不下，然后放到old代，但是old代也没有空间容纳晋升的对象，导致了fullgc。原理虽然如此，但是我们应用很少的对象可以存活到年老代才对，怎么会年老代这么多对象呢，于是mat大杀器出马，
得到的提示是String对象，为了搞清楚String对象是否在old代中，使用如下oql查询查了一下:`SELECT toString(s) FROM java.lang.String s WHERE (((s.value.@length < 150) and (s.value.@length > 100) and (s.value != null)) and (toString(s) LIKE “.file:.”))

SELECT toString(s.value) FROM java.lang.StringBuilder s WHERE ((s.value.@length > 1000) and (s.@retainedHeapSize > 1000))

select * from java.lang.StringBuilder s where s.@retainedHeapSize > 1000 and s.@displayName.contains(“StringBuilder”)

SELECT * FROM java.lang.Class c WHERE c.@displayName.contains(“StringBuilder”)

SELECT * FROM INSTANCEOF java.lang.Object t WHERE (toHex(t.@objectAddress) <= “0x770000000”)

SELECT * FROM java.lang.Class c WHERE toHex(c.@objectAddress) < “0x770000000”`
以上的0x77000000地址是通过-XX:+PrintHeapAtGC参数打印出来的新生代和年老代的分界值，
看到这里这些大的字符串对象在年老代中，我一脸惊愕，按理说这些对象应该是要在新生代回收的才对，因为其实这些对象并没有大到可以直接进入年老代的程度，于是看了ygc的频率，发现问题点的ygc频率非常频繁，old带的内存占用一直增加，猜测肯定是这些对象提前升级到年老代了，于是做了如下优化： 减少年老代内存到2G，增加新生代内存到4G，重启容器观察，ygc频率从5s一次变成了20s一次,ygc的停顿时间几乎不变，每次ygc后年老代的内存占用几乎保持不变，重新导出年老代的内存到mat分析，发现已经没有大的临时String对象了，问题解决