我们都知道gc是为了释放内存,但是你是否碰到过ygc前后新生代反增不减的情况呢?gc日志效果类似下面的:
2016-05-18T15:06:13.011+0800: [GC [ParNew (promotion failed): 636088K->690555K(707840K), 0.2958900 secs][CMS: 1019739K->1019733K(1310720K), 2.6208600 secs] 1655820K->1655820K(2018560K), [CMS Perm : 205486K->205486K(262144K)], 2.9174390 secs] [Times: user=3.74 sys=0.01, real=2.91 secs]
从上面的gc日志来看,我们新生代使用的是ParNew,而老生代用的是CMS GC,我们注意到ParNew的效果是新生代从636088K新增到了690555K,这是什么情况?
要解释这个问题,我们先要弄清楚YGC的过程,parNew是新生代的gc算法,简单来说从gc roots开始扫描对象,当扫到一个只要是属于新生代的对象就将其挪到to space,但是老的对象还不会做释放,直到gc完成之后再看是否释放老的对象(比如说上面我们看到了 promotion failed
的关键字,意味着晋升失败了,也就是说to和old都装不下新生代晋升来的对象,那么在这种情况下其实是不会对eden和from里的老对象做释放的,尽管to space里已经可能存在一份副本了),但是在gc前后不管是否晋升成功,都会对from space和to space做一个对换,也就是原来的from变成to,原来的to变成from,再来看看打印gc前后内存变化的代码
void GenCollectedHeap::print_heap_change(size_t prev_used) const { if (PrintGCDetails && Verbose) { gclog_or_tty->print(" " SIZE_FORMAT "->" SIZE_FORMAT "(" SIZE_FORMAT ")", prev_used, used(), capacity()); } else { gclog_or_tty->print(" " SIZE_FORMAT "K" "->" SIZE_FORMAT "K" "(" SIZE_FORMAT "K)", prev_used / K, used() / K, capacity() / K); } } size_t GenCollectedHeap::used() const { size_t res = 0; for (int i = 0; i < _n_gens; i++) { res += _gens[i]->used(); } return res; } size_t DefNewGeneration::used() const { return eden()->used() + from()->used(); // to() is only used during scavenge }
从上面代码我们知道,gc之后的内存情况是used()方法返回的,其中新生代的used方法返回的是eden+from的内存,同样的上面的prev_used也是这么计算的,只是发生在gc之前,这样一来,根据我上面提到的情况,在gc之后不管是否成功都会做一次from和to的swap,那么gc之前新生代的使用大小,其实是gc之前eden+from的使用大小,而gc之后的新生代的使用大小,其实是eden+原来的to现在是使用的大小,原来的to现在使用的大小其实就是在gc过程中将eden和from拷贝过来的对象所占的大小。
综上分析你应该知道为什么会出现这种情况了,其实是一种特殊情况,只有在出现 promotion failed
的情况下才会发生这样的情况,因为在这个情况下存在to里新增对象,而from和eden不会变化的情况