1. 对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够的空间时，虚拟机将发起一次Minor GC。在如下的测试代码中，尝试分配3个2MB大小和1个4MB大小的对象，在运行时通过参数-Xmx20M，-Xms20M,-Xmn10M这三个参数限制了java堆大小为20MB，不可扩展，其中10MB分配给新生代，剩下的非配给老年代。-XX:SurvivorRatio=8决定了新生代中Eden区与一个Survivor区的比例为8:1，即 Eden: from Survivor：to Survivor = 8:1:1，即8MB:1MB:1MB，，新生代的可用空间为9MB。
package test1;class TestGc {private static final int _1MB = 1024 * 1024;/** -verbose:gc-Xms20m-Xmx20m-Xmn10m-XX:+UseSerialGC-XX:+PrintGCDetails-XX:SurvivorRatio=8 * @param args */public static void main(String[] args) {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];//出现一次Monor GC}}
对上面的一段代码简单分析：
Eden: from Survivor：to Survivor = 8MB:1MB:1MB；
分配allocation1、allocation2、allocation三个对象到Eden区，占6MB空间；分配allocation4时 发现Eden剩余空间2MB不够分配，因此发生Minor GC，GC期间又发现已有的3个2MB的对象都无法放入Survivor空间（1MB），所以通过担保机制提前转移到老年代区（3个2MB的对象），此时Eden区恢复到8MB空间，然后将allocation4分配到Eden空间。
运行结果：
[GC [DefNew: 6487K->160K(9216K), 0.0155080 secs] 6487K->6305K(19456K), 0.0155918 secs] [Times: user=0.00 sys=0.02, real=0.02 secs]Heapdef new generation total 9216K, used 4584K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) eden space 8192K, 54% used [0x00000000f9a00000, 0x00000000f9e51f98, 0x00000000fa200000) from space 1024K, 15% used [0x00000000fa300000, 0x00000000fa3283d0, 0x00000000fa400000) to space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000)tenured generation total 10240K, used 6144K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000) the space 10240K, 60% used [0x00000000fa400000, 0x00000000faa00030, 0x00000000faa00200, 0x00000000fae00000)compacting perm gen total 21248K, used 2981K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000) the space 21248K, 14% used [0x00000000fae00000, 0x00000000fb0e96a0, 0x00000000fb0e9800, 0x00000000fc2c0000)No shared spaces configured.
下面的结果是上面这段代码去掉-XX:+UseSerialGC参数后的（我的环境默认采用的是Parallel Scavenge收集器），没有发生Minor GC，为什么呢？这是因为不同的收集器收集策略不同（可以看下下面的Minor GC和 Full GC的差别就明别了）。
HeapPSYoungGen total 9216K, used 6651K [0x00000000ff600000, 0x0000000100000000, 0x0000000100000000) eden space 8192K, 81% used [0x00000000ff600000,0x00000000ffc7eec8,0x00000000ffe00000) from space 1024K, 0% used [0x00000000fff00000,0x00000000fff00000,0x0000000100000000) to space 1024K, 0% used [0x00000000ffe00000,0x00000000ffe00000,0x00000000fff00000)PSOldGen total 10240K, used 4096K [0x00000000fec00000, 0x00000000ff600000, 0x00000000ff600000) object space 10240K, 40% used [0x00000000fec00000,0x00000000ff000010,0x00000000ff600000)PSPermGen total 21248K, used 2972K [0x00000000f9a00000, 0x00000000faec0000, 0x00000000fec00000) object space 21248K, 13% used [0x00000000f9a00000,0x00000000f9ce71e0,0x00000000faec0000)
Minor GC和 Full GC:
新生代GC(Minor GC):只发生在新生代的垃圾收集动作，因为java对象大多数都具备朝生夕灭的特性，所有Minor GC非常频繁，一般回收速度也比较快。
老年代GC(Major GC/Full GC):只发生在老年代的GC,出现了Full GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge 收集器的收集策略就有直接进行Full GC的策略选择过程）。Full GC的速度一般会比Minor GC慢10倍以上。
2.大对象直接进入老年代
所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组。大对象对虚拟机的对象分配来说是一个坏消息，经常出现大对象容易导致内存还有不少空间就提前触发垃圾收集器以获得足够的连续空间来安置它们。
/**-verbose:gc -Xms20m-Xmx20m-Xmn10m-XX:+PrintGCDetails-XX:SurvivorRatio=8-XX:+UseSerialGC-XX:PretenureSizeThreshold=3145728（3MB） */public static void test2(){byte[] allocation1; allocation1 = new byte[4 * _1MB];}运行结果：
Heapdef new generation total 9216K, used 507K [0x00000000f9a00000, 0x00000000fa400000, 0x00000000fa400000) eden space 8192K, 6% used [0x00000000f9a00000, 0x00000000f9a7ee98, 0x00000000fa200000) from space 1024K, 0% used [0x00000000fa200000, 0x00000000fa200000, 0x00000000fa300000) to space 1024K, 0% used [0x00000000fa300000, 0x00000000fa300000, 0x00000000fa400000)tenured generation total 10240K, used 4096K [0x00000000fa400000, 0x00000000fae00000, 0x00000000fae00000) the space 10240K, 40% used [0x00000000fa400000, 0x00000000fa800010, 0x00000000fa800200, 0x00000000fae00000)compacting perm gen total 21248K, used 2973K [0x00000000fae00000, 0x00000000fc2c0000, 0x0000000100000000) the space 21248K, 13% used [0x00000000fae00000, 0x00000000fb0e7428, 0x00000000fb0e7600, 0x00000000fc2c0000)No shared spaces configured.
3.长期存活的对象进入老年代即使爬到最高的山上，一次也只能脚踏实地地迈一步。
