Young GC 最喜欢“快生快死”的“爽快型”object了,大量对象跟垃圾收集器连照面都没打一个就bye-bye了。copy型GC算法的速度只跟新生代GC时刻的live objects个数相关。
好了,我举个我工作过的互联网某司的服务器应用的例子吧,例举的数据保证数量级是正确的,就这么个意思吧。该应用的SLA (Service Level Agreement) 是反应时间95% percentile在100ms以内。
所以,我们定的是让Young GC 控制在30ms,CMS GC尽量推延发生,以保证应用本身有足够的时间来做运算。正因为我们的service是要求100ms以内完成,其实就意味着新生代在Young GC 发生时其实堆满大量的floating object,Young GC 工作量并没有那么大;能promoted到老生代有很大一部分都是load进来的各种cache。
2015年前G1 GC还打磨得不够成熟,GC算法我们选型定的是CMS GC。32核服务器,Heap大小开的20G吧,新生代5G,其他参数根据上述要求微调了一下下。
结果就是:5s左右发生一次Young GC,停顿25ms吧,CMS GC至少要几小时甚至一天才发生一次,满意地完成了上述SLA 条件。
------------------------------
其实,在短时间内大量创建、消亡的对象们是垃圾收集器的最爱:可能根本就见不着面