概述
Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存。关于回收内存这一点，我们已经使用了大量篇幅去介绍虚拟机中的垃圾收集器体系以及运作原理，现在我们再一起来探讨一下给对象分配内存的那点事儿。
对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分之百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。
接下来我们将会讲解几条最普遍的内存分配规则，并通过代码去验证这些规则。由于条件因素，只能在Client模式下测试，因此CMS和G1并未提及。
本文地址：http://blog.csdn.net/v123411739/article/details/78941793
1.对象优先在Eden分配
大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。
例子1：
Serial + Serial Old（UseSerialGC） 或者 ParNew + Serial Old（UseParNewGC）
GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：当要分配allocation5时，Eden空间不足，进行Minor GC，此时年轻代空间从76595K降低到698K。这是由于allocation1、allocation2、allocation3、allocation4对象的大小皆超过Survivor空间大小（10M），因此allocation1、allocation2、allocation3、allocation4对象皆通过分配担保机制提前转移到老年代，年轻代剩余的698k为JVM的内部对象，进行Minor GC后进入了Survivor区。
例子2：
Parallel Scavenge + Parallel Old
GC环境：垃圾收集器为Parallel Scavenge + Parallel Old，年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：当要分配allocation5时，Eden空间不足，进行Minor GC，此时年轻代空间从76595K降低到888k。这是由于allocation1、allocation2、allocation3、allocation4对象的大小皆超过Survivor空间大小（10M），因此allocation1、allocation2、allocation3、allocation4对象皆通过分配担保机制提前转移到老年代，年轻代剩余的888k为JVM的内部对象，进行Minor GC后进入了Survivor区。后面的Full GC会在后面的空间分配担保进行讲解。
例子3：
Parallel Scavenge + Parallel Old
GC环境：垃圾收集器为Parallel Scavenge + Parallel Old，年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：该例子跟例子2的区别是把例子2的最后两次分配10M和30M合并成了1次分配40M，结果没有进行GC，原因是在Parallel Scavenge收集器下：将要分配的对象大小 >= Eden总空间的一半，对象通过分配担保机制直接进入老年代，否则尝试进行MinorGC。
2.大对象直接进入老年代
所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串以及数组（例子中的byte[]数组就是典型的大对象）。
虚拟机提供了一个-XX：PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。只对Serial和ParNew两款收集器有效，Parallel Scavenge收集器不认识这个参数，Parallel Scavenge收集器一般并不需要设置。
例子1：没设置PretenureSizeThreshold
GC分析：可以看出老年代为空，allocation对象正常进入新生代。
例子2：设置PretenureSizeThreshold=3145728
GC分析：可以看出老年代被占用了4M，allocation对象由于超过PretenureSizeThreshold设置的3M（3145728 = 3 * 1024 * 1024），被认为是大对象直接进入老年代。
3.长期存活的对象将进入老年代
如果对象在Eden出生并经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中每“熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。
例子1：不设置MaxTenuringThreshol参数
GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：没设置MaxTenuringThreshold时，MaxTenuringThreshold的默认值为15，必须经过15次Minor GC才能晋升到老年代，因此经过该例子经过两次Minor GC后，年轻代仍有3257k，即allocation1对象的仍在Survivor区。
例子2：设置参数MaxTenuringThreshold=1
GC分析：该例子跟上面差别只有一个，将MaxTenuringThreshold设为1，可以看出第二次Minor GC时，年轻代已经被清空，allocation1对象因为年龄符合MaxTenuringThreshold设置的值，因此进入老年代。
4.动态对象年龄判断
如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
例子1：allocation1+allocation2大于Survivor空间一半
GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：allocation3分配时，Eden空间不足，因此触发第一次Minor GC，allocation1和allocation2对象进入Survivor区，allocation3由于太大，直接进入老年代。当第二次分配allocation4时，Eden空间不足（allocation4虽然已经=null，但是由于还未进行垃圾收集，因此空间仍未释放），触发第二次Minor GC，可以看到此时年轻代GC后为空，可以得出Survivor里面的allocation1和allocation2已经进入老年代，原因是Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半。
例子2：allocation1+allocation2小于Survivor空间一半
GC分析：该例子跟上面的例子只差在allocation1大小从10M/4变成了10M/8，从而导致allocation1+allocation2的对象大小没有大于Survivor空间的一半，因此第二次Minor GC后，年轻代大小依然为4537k，allocation1和allocation2仍然在Survivor区。
5.空间分配担保
JDK 6 Update 24之后：在发生Minor GC之前，虚拟机会先检查老年代的连续空间大小是否大于新生代对象总大小或者历次晋升的平均大小, 如果是则进行Minor GC, 否则将进行Full GC。
Parallel Scavenge收集器与其他收集器在空间分配担保上有一点差别, 正常是在Minor GC前进行检查, 而Parallel Scavenge收集器在Minor GC后也会进行检查。
另外当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。
例子1：
Serial + Serial Old（UseSerialGC） 或者 ParNew + Serial Old（UseParNewGC）
GC环境：垃圾收集器为Serial + Serial Old（ParNew + Serial Old），年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：allocation1、allocation2、allocation3占用了Eden的60M空间，allocation4分配内存时，Eden的空间已经不足，因此触发第一次Minor GC，Minor GC结束后，allocation1、allocation2、allocation3进入老年代，此时老年代剩余空间为40M，GC后剩余的698k为JVM内部对象进入其中一个Survivor。allocation7分配内存时，此时年轻代已经放了allocation4、allocation5、allocation6，已经无法放下allocation7，因此将触发Minor GC，但在触发前会进行检查，此时老年代剩余空间为不足40M，新生代的对象总大小为60M，历次晋升的平均大小为60M，因此改为进行一次Full GC，Full GC后，年轻代对象被全部晋升，老年代因为allocation1、allocation2、allocation3被赋空，内存得到回收，晋升上来allocation4、allocation5、allocation6，因此内存大小还是60M左右，但是后面的堆总量可以看到由120M降低到了60M。
例子2：
Parallel Scavenge + Parallel Old
GC环境：垃圾收集器为Parallel Scavenge + Parallel Old，年轻代大小为100M，Eden：Survivor = 8 ：1，所以Eden为80M，两个Survivor各10M，老年代为100M。
GC分析：allocation1、allocation2、allocation3占用了Eden的60M空间，allocation4分配内存时，Eden的空间已经不足，因此触发第一次Minor GC，Minor GC结束后，allocation1、allocation2、allocation3进入老年代，此时老年代剩余空间为40M，GC后剩余的904k为JVM内部对象进入其中一个Survivor。由于Parallel Scavenge的特殊性（在Minor GC后也会检查老年代的空间），此时检查到剩余空间40M小于历次晋升的平均大小（此时只有1次晋升, 因此晋升的平均大小为60M），因此触发第一次Full GC，将年轻代的所有对象晋升到老年代，因此Full GC后年轻代空间为空，老年代略微增长。allocation7分配内存时，此时年轻代已经放了allocation4、allocation5、allocation6，已经无法放下allocation7，因此将触发Minor GC，但在触发前会进行检查，此时老年代剩余空间为不足40M，新生代的对象总大小为60M，历次晋升的平均大小为60M，因此改为进行一次Full GC，Full GC后，年轻代对象被全部晋升，老年代因为allocation1、allocation2、allocation3被赋空，内存得到回收，晋升上来allocation4、allocation5、allocation6，因此内存大小还是60M左右，但是后面的堆总量可以看到由120M降低到了60M。