JVM的内存分配与回收策略实战——对象优先在Eden分配

本文代码在测试时使用的垃圾收集器组合是Serial/Serial Old。
这里还需要介绍一些JVM的基本参数，本文中进行如下设置：
-verbose gc 打印垃圾收集信息
-Xms20M 堆容量设置为20MB
-Xmx20M 堆容量最大值设置为20MB
-Xmn10M 新生代容量设置为10MB（老年代20-10=10MB）
-XX：SurvivorRatio=8（新生代Eden和Survivor的大小比例为8：1：1）
-XX：+PrintGCDetails 打印GC详情
-XX:+UseSerialGC 使用Serial+SerialOld垃圾收集器组合

大多数情况下对象在新生代的Eden区分配，当Eden区没有足够的空间时，虚拟机将发起一次Minor GC。

public class CmsTest {
    public static void main(String[] args) {
        int size=1024*1024;

        byte[] myAlloc1=new byte[2*size];

        byte[] myAlloc2=new byte[2*size];

        byte[] myAlloc3=new byte[2*size];

        byte[] myAlloc4=new byte[4*size];

    }
}

在以上代码中，尝试分配3个2MB大小和1个4MB大小的对象，根据GC信息可得出：分配myAlloc4时发生了MinorGC，新生代 DefNew: 7127K->519K，但是总内存空间几乎没有减少7127K->6663K（因为myAlloc1，myAlloc2，myAlloc3三个对象都是存活的）。发生这次GC的原因是给myAlloc4分配内存时，Eden已被前三个对象占用6MB，剩余容量不足以分配4MB内存（虽然一共10MB，但还会被其他系统默认东西占用小部分内存），因此发生了MinorGC。GC期间发现已有的3个2MB大小的对象无法全部放入Survivor空间中（Survivor只有1MB空间），所以根据分配担保机制提前转移到老年代。
因此这次GC结束后，myAlloc4分配到了新生代Eden中，结果是Eden占用4MB，老年代被占用6MB（被myAlloc1-3三个对象占用）。