六、内存分配与回收策略

Java技术体系中所倡导的自动内存管理最终可以归纳为自动化解决了两个问题：给对象分配内存以及回收分配给对象的内存。对象的内存分配，往大方向讲，就是在堆上分配（但也可能经过JIT编译后被拆散为标量类型并间接地栈上分配），对象主要分配在新生代的Eden区上，如果启动了本地线程分配缓冲，将按线程优先在TLAB上分配。少数情况下也可能会直接分配在老年代中，分配的规则并不是百分百固定的，其细节取决于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

6.1 对象优先在Eden分配

大多数情况下，对象在新生代Eden区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次Minor GC。虚拟机提供了-XX:+PrintGCDetails这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。

private static fianl int _1MB = 1024 * 1024;
/*
    VM参数：-verbose:gc -Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRation=8
*/

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
}

运行结果：

说明：

代码中可以看到，尝试分配三个2MB大小和一个4MB大小的对象，在运行时通过-Xms20M、-Xmx20M、-Xmn10M这三个参数限制了Java堆大小为20MB，不可扩展，其中10MB分配给老年代。-XX:SurvivorRation=8决定了新生代中Eden区与一个Survivor区的空间比例是8:1，于是新生代总的可用空间是9216KB。
从运行结果可以看到，在分配allocation4对象的语句时会发生一次Minor GC，从结果第一行可以看到，新生代占用空间从6651-->148，但是需要知道，在发生GC的时候，首先要将Eden空间中的对象向一个Survivor区中转移，但是这里Survivor空间只有1MB，那只好转移到老年代中去了，所以，看以看到发生GC的时候堆的总占用量并没有减少（6651K-->6292K(19456K)可以看出，因为之前的三个对象并没有死亡），而老年代被占用60%（从the space 10240K, 60%可以看出，3个对象总共占用6M，老年代有10M），之后分配的第四个对象占用4M，而Eden为8M，所以占用50%左右（从eden space 8192, 51%看出），这里form space占用14%可能是一些其他信息吧（不太确定），而to space因为存活对象都转移到老年代中去了，所以这里没有占用。这里借用一张图（http://www.jianshu.com/p/fab8865f9b79）

2

Minor GC 和 Full GC 的区别

新生代GC（Minor GC）：指发生在新生代的垃圾收集动作，因为Java对象大多都是具备朝生夕灭的特性，所有Minor GC非常频繁，一般回收速度也比较快。
老年代GC（Major GC/ Full GC）：指发生在老年代的GC，出现了Major GC，经常会伴随至少一次的Minor GC（但非绝对的，在Parallel Scavenge收集器的收集策略里就有直接进行Major GC的策略选择过程）。Major GC的速度一般会比Minor GC慢十倍以上。

6.2 大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的Java对象，最典型的大对象就是那种很长的字符串或数组，之前例子中就是数组大对象。大对象在内存中有时候不太好处理，会导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置”它们。虚拟机中提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配，这样做的目的是避免在Eden区以及两个Survivor区之间发生大量的内存复制。下面通过例子说明：

说明：从运行结果来看，新生代根本就没有使用，因为我们设置的 XX:PretenureSizeThreshold参数值为 3145728bit（即 3MB），而分配的对象为 4MB，所以直接在老年代中分配，于是老年代被占用 40%。
注意： XX:PretenureSizeThreshold参数只对 Serial和 ParNew有效， Parallel Scavenge不认识此参数， Parallel Scavenge一般并不需要设置。如果遇到必须使用此参数的场合，可以考虑 ParNew加 CMS的收集器组合。

6.3 长期存活的对象将进入老年代

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代中。这里，虚拟机中使用对象年龄（Age）计数器来完成此目的。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且对象年龄设为1。对象在Survivor区中没“熬过”一次Minor GC，年龄就增加一岁，当它的年龄增加到一定程度（默认为15岁），就将会被晋升到老年代中。对象晋升老年代的阈值可以通过参数-XX:MaxTenuringThreshold设置。

下面对同一个代码设置不同的-XX:MaxTenuringThreshold值来进行说明：

程序代码：

4
以MaxTenuringThreshold=1参数来运行的结果：

5

6
以MaxTenuringThreshold=15参数来运行的结果：

7

说明：对象allocation1需要256K的内存，Survivor空间能够容纳。当MaxTenuringThreshold=1时，allocation1对象在第二次GC发生时进入老年代，新生代已使用的内存GC后非常干净地变成了0KB。而MaxTenuringThreshold=15时，第二次发生GC后，allocation1对象则还留在新生代Survivor空间，这时新生代仍然有404KB被占用。（这里没有完全弄懂）

6.4 动态对象年龄判定

为了能更好地适应不同程序的内存状况，虚拟机并不是永远地要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。下面通过代码说明：

说明：这里设置 MaxTenuringThreshold=15，会发现运行结果中 Survivor的空间占用仍然为 0，而老年代比预期增加了 6%，即 allocation1、allocation2对象都直接进入了老年代，而没有等到 15岁的临界值。因为这两个对象加起来已经达到 512KB，并且它们是同年的，满足了一半的规则。我们只需要注释掉其中一个对象 new操作，就会发现另外一个就不会晋升到老年代中了。

6.5 空间分配担保

在发生Minor GC之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。如果不成立，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。如果允许，那么会继续检查老年代最大可用的连续空间是否大于历次晋升到老年代对象的平均大小，如果大于，将尝试着进行一次Minor GC，尽管这次Minor GC是有风险的；如果小于，或者HandlePromotionFailure设置不允许冒险，那这是也要该为进行一次Full GC。

什么是“冒险”，前面提过，新生代使用复制收集算法，但为了内存利用率，只使用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。但是老年代本身不知道是否还有容纳这些对象的剩余空间，所以只好取之前每一次回收晋升到老年代对象容量的平均大小值作为经验值，与老年代的剩余空间进行比较，决定是否进行Full GC来让老年代腾出更多空间。

下面通过代码说明：

说明：取平均值进行比较其实仍然是一种动态概率的手段，如果某次 Minor GC存活胡的对象突增，远远高于平均值的话，仍然会导致担保失败（ Handle Promotion Failure）。如果出现失败，那就只好再次发起一次 Full GC。虽然担保失败时绕的圈子是最大的，但大部分情况下都还是会将 HandlePromotionFailure开关打开，避免 Full GC过于频繁。

上述内容感觉书上讲的不是很详细，有些东西还没搞懂，在以后补充！！！

5、垃圾收集与内存分配策略(4)（JVM笔记）