根据计算
-
整个堆空间3G
-
Eden区800M
-
s1/s2各100M
-
方法区512M
-
一个线程1M
按照这个模型来分析,得到如下结果:
-
大促期间1s产生80M的对象数据。我们知道对象数据都是放在Eden园区,Eden园区一共800M,那么大约10s就放满了,放满了就会触发Minor GC
-
触发Minor GC的期间,会Stop The World暂停业务线程。在第10s触发MinorGC的时候,前9s的720M数据都已经变成垃圾了,会被回收掉,最后1s的80M数据由于还有对象引用,只是暂停了业务线程,因此不是垃圾,不能被回收。会被放入S1区。
-
在Survivor区有一个对象动态年龄判断机制。什么是对象动态年龄判断机制呢?
当前放对象的Survivor区域里(其中一块区域,放对象的那块s区),一批对象的总大小大于这块Survivor区域内存大小的50%(-XX:TargetSurvivorRatio可以指定),那么此时大于等于这批对象年龄最大值的对象,就可以直接进入老年代了,
例如:Survivor区域里现在有一批对象,年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区域的50%,此时就会把年龄n(含)以上的对象都放入老年代。这个规则其实是希望那些可能是长期存活的对象,尽早进入老年代。
对象动态年龄判断机制一般是在minor gc之后触发的。
也就是说当在Survivor区经过几代的回收以后,如果对象总和大于Survivor区域的一半,则会直接放入到老年代。Survivor是100M,第10s的对象是80M,大于100M,会直接将这个对象放入到老年代。
- 老年代一共有2G空间,2G空间执行多少次会满呢?2G/80M=25次,也就是发生25次(25秒)Minor GC就会触发一次Full GC。这个频率就太高了,通常应该要很少触发Full GC,起码也得1个小时触发一次。而触发的原因是因为垃圾对象(这些对象1s后都变成垃圾了),这样肯定是不行的。我们需要优化JVM参数。
3. JVM优化
=========
有问题有就解决问题。问题的根本原因是老年代发生了Full GC,为什么会发生Full GC呢?
之所以80M对象会放到了老年代是因为每秒产生的数据 大于 Survivor区空间的一半。所以,我们可以调整Survivor区大小。通常我们不会修改默认的Eden:S1:S2的比例,所以,我们可以考虑从整体扩大新生代的内存空间。假设我们扩大到2G,让老年代是1G。