JVM内存分配担保机制

在JVM的内存分配时，也有这样的内存分配担保机制。就是当在新生代无法分配内存的时候，把新生代的对象转移到老生代，然后把新对象放入腾空的新生代。

现在假设，我们的新生代分为三个区域，分别为eden space，from space和to space。

现在是尝试分配三个2MB的对象和一个4MB的对象，然后我们通过JVM参数 -Xms20M、-Xmx20M、-Xmn10M 把Java堆大小设置为20MB，不可扩展。

其中10M分配给新生代，另外10M分配给老生代。

然后我们通过-XX：SurvivorRatio=8来分配新生代各区的比例，设置为8，表示eden与一个survivor区的空间比例为8:1。

JVM参数配置：

-Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC

这里我们先手动指定垃圾收集器为客户端模式下的Serial+Serial Old的收集器组合进行内存回收。

由于不同的收集器的收集机制不同，为了呈现出内存分配的担保效果，我们这里需要手动指定为Serial+Serial Old模式。

另外担保机制在JDK1.5以及之前版本中默认是关闭的，需要通过HandlePromotionFailure手动指定，JDK1.6之后就默认开启。这里我们使用的是JDK1.8，所以不用再手动去开启担保机制。

下面我们新建四个byte数组，前三个分别为2MB大小的内存分配，第四个是4MB的内存分配。代码如下

package com.c06;

public class HandlePromote {
	private static int _1mb = 1024 * 1024;

	public static void testHandlePromotion() {
		byte[] allocation1, allocation2, allocation3, allocation4;
		allocation1 = new byte[2 * _1mb];
		allocation2 = new byte[2 * _1mb];
		allocation3 = new byte[2 * _1mb];
		allocation4 = new byte[4 * _1mb];
	}

	public static void main(String[] args) {
		HandlePromote.testHandlePromotion();
	}
}

打印日志

[GC (Allocation Failure) [DefNew: 7128K->520K(9216K), 0.0046620 secs] 7128K->6664K(19456K), 0.0047421 secs] [Times: user=0.00 sys=0.02, real=0.00 secs] 
Heap
 def new generation   total 9216K, used 4698K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
  eden space 8192K,  51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
  from space 1024K,  50% used [0x00000000ff500000, 0x00000000ff582258, 0x00000000ff600000)
  to   space 1024K,   0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
 tenured generation   total 10240K, used 6144K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
   the space 10240K,  60% used [0x00000000ff600000, 0x00000000ffc00030, 0x00000000ffc00200, 0x0000000100000000)
 Metaspace       used 2651K, capacity 4486K, committed 4864K, reserved 1056768K
  class space    used 282K, capacity 386K, committed 512K, reserved 1048576K

通过GC日志我们发现在分配allocation4的时候，发生了一次Minor GC，让新生代从7836K变为了472K，但是你发现整个堆的占用并没有多少变化。这是因为前面三个2MB的对象都还存活着，所以回收器并没有找到可回收的对象。但为什么会出现这次GC呢？
图2 正常流程把前三个对象放入了新生代Eden区
如果你算一笔账就知道了，前面三个对象2MB+2MB+2MB=6MB。
虚拟机分配内存优先会分配到新生代的eden space，通过图1我们知道新生代可用内存一共只有9216KB，现在新生代已经被用去了6MB，还剩下9216KB-6144KB=3072KB，然而第四个对象是4MB，显然在新生代已经装不下了。

图3 第四个对象此时无法放入Eden区

于是发生了一次Minor GC！

而且本次GC期间，虚拟机发现eden space的三个对象（6MB）又无法全部放入Survivor空间(Survivor可用内存只有1MB)。

这时候该怎么办呢？第四个对象还要不要分配呢？

此时，JVM就启动了内存分配的担保机制，把这6MB的三个对象直接转移到了老年代。

此时就把新生代的空间腾出来了，然后把第四个对象（4MB）放入了Eden区中，所以你看到的结果是4096/8192=0.5，也就是约50%：
老年代则被占用了6MB，也就是前三个对象，
102423=6144KB，6144KB/10240KB=0.6也就是60%：
the space 10240K, 60% used [0x00000007bf600000, 0x00000007bfc00030, 0x00000007bfc00200, 0x00000007c0000000)