在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)