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]
Heap
def 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的差别就明别了）。
Heap
PSYoungGen 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];
}
运行结果：
Heap
def 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.长期存活的对象进入老年代
既然虚拟机采用了分代收集的思想来管理内存，那么内存回收是就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄（Age）计数器。如果对象如果对象在Eden出生并经历了一次Minor GC 后仍然存活，并且能被Survivor容纳的话，将被移到Survivor空间中，并且年龄设为1.对象在Survivor中每熬过一次 Minor GC,对象的年龄加1岁，年龄加到一定的程度（默认是15），就会被晋升到老年代中。
对象老年代的阈值可以可以通过参数-XX:MaxTenuringThreshold设置。
4.动态对象年龄判断
为了更好的适应不同程序的内存状况，虚拟机并不是永远的要求对象的年龄必须达到MaxTeburingThreshold才能晋升为老年代，如果Survivor空间中相同年龄的所有对象大小的总和超多Survivor空间的一半，年龄大于或者等于该年龄的对象就可以直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄。
5. 空间分配担保
在发生MInor GC 之前，虚拟机会首先检查老年代最大可用的连续空间是否大于新生代所有对象的总和，如过这个条件成立，那么Minor GC 可以确保是安全的。如果不成立，则虚拟机会查看HandelPromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代连续的可用的空间大小是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试一次Minor GC ，尽管这次Minor GC 是有风险的；如果小于或者HandelPromotionFailure设置不允许冒险，那这是也要进行一次Full
GC。
-XX:-HandelPromotionFailure=false。