1.对象优先在Eden分配
接下来在如下的代码片段testAllocation()方法中 ，我们尝试分配三个2MB大小和一个4MB大小的对象， 在运行
时通过-Xms20M、 -Xmx20M、 -Xmn10M这三个参数限制了Java堆大小为20MB， 不可扩展， 其中
10MB分配给新生代， 剩下的10MB分配给老年代。 -XX： Survivor-Ratio=8决定了新生代中Eden区与一
个Survivor区的空间比例是8∶ 1
/**
* VM参数： -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
* 这里我们先手动指定垃圾收集器为客户端模式下的Serial+Serial Old的收集器组合进行内存回收。
* 由于不同的收集器的收集机制不同，为了呈现出内存分配的担保效果，我们这里需要手动指定为Serial+Serial Old模式。
*/
public class Test {
private static final int _1MB = 1024 * 1024;
public static void testAllocation() {
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]; // 出现一次Minor GC
}
public static void main(String[] args) {
testAllocation();
}
}
输出打印结果：
[GC (Allocation Failure) [DefNew: 7808K->603K(9216K), 0.0062181 secs] 7808K->6747K(19456K), 0.0074891 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
Heap
def new generation total 9216K, used 4781K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
from space 1024K, 58% used [0x00000000ff500000, 0x00000000ff596d10, 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 3199K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 346K, capacity 388K, committed 512K, reserved 1048576K
从输出的结果也清晰地看到“eden space 8192K、 from space 1024K、 to space 1024K”的信息， 新生代总可用空间为9216KB（Eden区+1个Survivor区的总容量） 。
当前三个对象分配进内存的时候如下：（当allocation4分配的时候会发生什么操作呢？）
执行testAllocation()中分配allocation4对象的语句时会发生一次Minor GC， 这次回收的结果是新生代7808KB变为603KB。而总内存占用量则几乎没有减少（因为allocation1、 2、 3三个对象都是存活的， 虚拟机几乎没有找到可回收的对象） 。
产生这次垃圾收集的原因是为allocation4分配内存时， 发现Eden已经被占用了6MB， 剩余空间已不足以分配allocation4所需的4MB内存， 因此发生Minor GC。 垃圾收集期间虚拟机又发现已有的三个2MB大小的对象全部无法放入Survivor空间（Survivor空间只有1MB大小） ， 所以只好通过分配担保机制提前转移到老年代去。
这次收集结束后， 4MB的allocation4对象顺利分配在Eden中。 因此程序执行完的结果是Eden占用4MB（被allocation4占用） ， Survivor空闲， 老年代被占用6MB（被allocation1、 2、 3占用） 。 通过GC日志可以证实这一点。 （tenured generation total 10240K, used 6144K）
2大对象直接进入老年代
大对象就是指需要大量连续内存空间的Java对象， 最典型的大对象便是那种很长的字符串， 或者元素数量很庞大的数组， 上述例子中的byte[]数组就是典型的大对象。 大对象对虚拟机的内存分配来说就是一个不折不扣的坏消息， 比遇到一个大对象更加坏的消息就是遇到一群“朝生夕灭”的“短命大对象”， 我们写程序的时候应注意避免。
在Java虚拟机中要避免大对象的原因是， 在分配空间时， 它容易导致内存明明还有不少空间时就提前触发垃圾收集， 以获取足够的连续空间才能安置好它们， 而当复制对象时， 大对象就意味着高额的内存复制开销。 试想一下，一个大对象屡次躲过GC，还要不停在两个Survivor区域里复制来复制去才能进入老年代，这本身就是一个很耗时间和效率的事儿。
HotSpot虚拟机提供了-XX： PretenureSizeThreshold 参数， 指定大于该设置值的对象直接在老年代分配， 这样做的目的就是避免在Eden区及两个Survivor区之间来回复制， 产生大量的内存复制操作 。
示例代码如下：
/**
* VM参数： -verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=8 -XX:+UseSerialGC
* -XX:PretenureSizeThreshold=3145728 这个参数不能与-Xmx之类的参数一样直接写3MB，需要转换为byte
*/
public class Test2 {
private static final int _1MB = 1024 * 1024;
public static void testAllocation() {
byte[] allocation;
allocation = new byte[4 * _1MB];
}
public static void main(String[] args) {
testAllocation();
}
}
输出结果：
Heap
def new generation total 9216K, used 1857K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000)
eden space 8192K, 22% used [0x00000000fec00000, 0x00000000fedd0750, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 4096K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000)
the space 10240K, 40% used [0x00000000ff600000, 0x00000000ffa00010, 0x00000000ffa00200, 0x0000000100000000)
Metaspace used 3223K, capacity 4496K, committed 4864K, reserved 1056768K
class space used 350K, capacity 388K, committed 512K, reserved 1048576K
Process finished with exit code 0
通过打印结果可以看到，新生代eden区使用的22%，也就是1802KB大小，显示不是对应的allocation对象；而我们的 tenured generation total 10240K, used 4096K，the space 10240K, 40% used 使用的4MB，刚好和allocation对象大小匹配；从而验证了一点，当我们的大对象超过3MB的时候，会直接进入老年代。
注意 -XX： PretenureSizeThreshold参数只对Serial和ParNew两款新生代收集器有效， HotSpot
的其他新生代收集器， 如Parallel Scavenge并不支持这个参数。 如果必须使用此参数进行调优， 可考虑
ParNew加CMS的收集器组合。
小结
本篇文章我们先介绍两种基本的对象分配，下篇文章我们将继续介绍长期存活的对象如何进入老年代以及动态年龄判断。
