第三章 垃圾回收器与内存分配策略

1.Copying算法补充

目前主流虚拟机对新生代的对象回收都是用的这种算法。IBM研究表明，新生代中的对象98％都是“朝生夕死”的，所以并不需要按照１: 1来划分内存，而是将内存分为一块较大的Eden和两块较小的Survivor，每次使用使用Eden和一块Survivor。当回收时，将Eden和Survivor中活着的对象全部复制到另一块Survivor中，然后清理掉Eden和原先的那一块Survivor中全部的对象。HotSpot虚拟机默认的分配空间是８: 1，当然我们没有办法保证每次回收都只有不多于10%的对象存活，当Survivor空间不够用时，需要依赖老年代进行分配担保。

2. 内存分配与回收策略

2.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden中分配，当Eden区没有空间时，虚拟机会发起一次MinorGC(在新生代中的垃圾回收动作)。来看书中提供的这个例子

/**
 * Created by cwj on 17-6-3.
 * VM:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8　-XX:+UseSerialGC
 */
public class TestMinorGC {

    public static final int _1MB = 1024 * 1024;

    public static void main(String[] args) {
        byte[] allocatioon1,allocatioon2,allocatioon3,allocatioon4;

        allocatioon1 = new byte[2 * _1MB];
        allocatioon2 = new byte[2 * _1MB];
        allocatioon3 = new byte[2 * _1MB];

        allocatioon4 = new byte[4 * _1MB];
    }
}

我使用的是idea+jdk1.8，所以与书中不同的是，要设置虚拟机使用Serial/Serial Old收集器，-XX:+UseSerialGC，如果不设置的话，idea会使用PS回收器，这样效果就不一样了。看看执行效果

执行效果

代码中，尝试分配3个2M大小和1个4M大小的对象，运行时通过设置虚拟机参数将堆大小定位20M且不可扩展，其中新/老生代各占10M。并且定义了Eden与Survivor比例是8:1，从输出结果也能看到：
eden space 8192K, from space 1024K, to space 1024K，其中新生代总共可用空间是9216KB(Eden+一个Survivor)。
　　执行到分配allocatioon4的空间是发生了一次MinorGC，结果是新生代从7581kb变到336kb，而总内存是7518kb变到6480kb，几乎没怎么变，因为1,2,3这三个对象都是存活的，并没有被回收。这次GC发生的原因是给4分配内存的时候,发现Eden已经被占用了6M，剩余的空间不足以分配4所需要的4M空间，所以发生了MinorGC。期间虚拟机又发现无法将3个2M大小的对象全部放入Survivor空间(因为Survivor只有1M)，所以只能通过担保机制，将3个对象转移到老年代中。
　　这次GC结束后，4M的allocation4对象被顺利的分配到了Eden中，因此程序执行结果是Eden占用了4M，Survivor空闲，老年代被占用了6M。

2.2 大对象直接进入老年代

所谓的大对象是指需要连续大量内存空间的Java对象，最典型的大对象就是那种很长的字符串和数组。经常出现大对象容易导致内存还有不少空间时就提前出发垃圾回收器以获得足够多的连续空间来安置他们
　　虚拟机提供了一个 -XX：PretenureSizeThreshold 参数，大于这个参数的对象直接进入老年代。这样做的目的是为了避免Eden和两个Survivor之间发生大量的内存复制。

/**
 * Created by cwj on 17-6-3.
 * VM:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 *    -XX：PretenureSizeThreshold=3145728
 *
 */
public class TestMinorGC {

    public static final int _1MB = 1024 * 1024;

    public static void main(String[] args) {
        byte[] allocatioon;
        allocatioon = new byte[4 * _1MB];
    }

}

执行结果.png

结果很清楚，因为我们预先设置了参数-XX：PretenureSizeThreshold=3145728，所以大于３Ｍ的对象直接就被分到了老年代中，所以老年代占了４Ｍ，新生代空闲。

2.3 长期存活的对象将进入老年代

虚拟机采用了分代收集的思想来管理内存，那么内存回+收时就必须知道哪些对象应该放在新生代，哪些放在老年代。为了做到这点，虚拟机给每个对象定义了一个年龄计数器。如果对象在Eden出生并经过一次GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设置为1。对象在Survivor中每熬过一次GC，年龄就增大一岁，当它的年龄增大到一定岁数时(默认15岁)，就会被移到老年代。当然这个默认值可以通过修改参数 -XX:MaxTenuringThreshold的值来改变。

/**
 * Created by cwj on 17-6-3.
 *
 * VM:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 *    -XX:MaxTenuringThreshold=1
 *    -XX:+PrintTenuringDistribution
 */
public class TestTenuringThreshold {
    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) {

        byte[] allocation1,allocation2,allocation3;

        allocation1 = new byte[_1MB / 4];
        allocation2 = new byte[4 * _1MB];
        allocation3 = new byte[4 * _1MB];
        //第一次GC

        allocation3 = null;
        allocation3 = new byte[4 * _1MB];
        //第二次GC
    }
}

执行结果

我们分析一下：首先1,2都被分到Eden中，当3第一次来时，Eden不够4M了，所以进行一次GC，将1放入Survivor，Age+1。又因为Survivor只有1M，不够4M，所以直接担保机制，2放入老年代。所以Eden从5726k->616k，总内存基本没变。
　　当第二次3进来时，发生第二次GC，将原来存在Eden中的3释放(赋值为null了),Survivor中的1已经1岁了，所以存入老年代，这时Eden刚释放完3，下一个3还没有进来，所以Eden从4712k->0,总内存由8808k->4706k，GC过后将新的3存入Eden。两次GC过后。Eden中存着的是3，老年代中存着的是2和1。
　　如果将参数 -XX:MaxTenuringThreshold值改为15，两次GC过后应该是Eden中存着3，Survivor中存着1，老年代中存着2.(理论是这样，然而我的idea中跑的结果还是跟参数为1的情况一样，很纳闷。。。)

2.4 动态对象年龄判定

为了能更好的适应不同程序的内存情况，虚拟机并不是永远要求对象的年龄必须达到MaxTenuringThreshold参数的值时才能晋升到老年代。如果在Survivor中所有相同年龄的对象大小的总和超过Survivor空间的一半，则年龄大于或等于该年龄对象就可以直接进入老年代，无需等到参数设定的年龄

/**
 * Created by cwj on 17-6-3.
 *
 * VM:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 *    -XX:MaxTenuringThreshold=15
 *    -XX:+PrintTenuringDistribution
 */
public class TestTenuringThreshold2 {
    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) {

        byte[] allocation1,allocation2,allocation3,allocation4;

        allocation1 = new byte[_1MB / 4];
        allocation2 = new byte[_1MB / 4];

        allocation3 = new byte[4 * _1MB];
        allocation4 = new byte[4 * _1MB];
        //第一次GC

        allocation4 = null;
        allocation4 = new byte[4 * _1MB];
        //第二次GC
    }
}

执行结果

可以看到结果中Survivor仍然是0，而老年代比预计的增加了6%，说明1,2并没有等到15岁就直接进入了老年代，因为这两个对象加起来的和已经达到了Survivor空间的一半，并且他们是同年的。我们只要注释掉一个，另外一个就不会进入老年代了。

2.5 空间分配担保

新生代不够放了就往老年代里面挪，那老年代也有不够的时候啊，这时候怎么办呢？如果老年代的连续空间大于新生代对象的总大小，或者历次晋升的平均大小，就可以进行安全的MinorGC，如果不大于那么就会执行一次FullGC来释放老年代的空间。

/**
 * Created by cwj on 17-6-3.
 *
 * VM:-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8
 *    -XX:+PrintTenuringDistribution
 */
public class TestTenuringThreshold3 {
    private static final int _1MB = 1024 * 1024;

    public static void main(String[] args) {

        byte[] allocation1,allocation2,allocation3,allocation4,allocation5,allocation6,allocation7;

        allocation1 = new byte[2 * _1MB];
        allocation2 = new byte[2 * _1MB];
        allocation3 = new byte[2 * _1MB];
        allocation1 = null;

        allocation4 = new byte[2 * _1MB];
        allocation5 = new byte[2 * _1MB];
        allocation6 = new byte[2 * _1MB];

        allocation4 = null;
        allocation5 = null;
        allocation6 = null;
        allocation7 = new byte[2 * _1MB];
    }
}

执行结果