内存分配与回收策略

小结；
内存回收与垃圾收集器在很多时候都是影响系统性能、并发能力的主要因素之一， 虚拟机之所以提供多种不同的收集器以及提供大量的调节参数，是因为只有根据实际应用需求，实现方式选择最优的收集方式才能获取最高的性能。 没有固定收集器、参数组合，也没有最优的调优方法，虚拟机也就没有什么必然 的内存回收方式， 因此，学习虚拟机内存知识，如果要到实践调优阶段，那么必须了解每个具体收集器的行为、优势和劣势、调节参数。

3.6 内存分配与回收策略

Java技术体系中所提倡的自动内存管理最终可以归结为自动化地解决了两个问题：给对象分配内存以及回收分配给对象的内存，关于回收内存这一点，之前已经讲过。

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

接下来我们将会讲解几条最普遍的内存分配规则，并通过代码去验证这些规则。 本节下面的代码在测试时会使用 Client 模式虚拟机运行， 没有手工指定收集器组合，换句话说，验证的是在使用 Serial / Serial Old 收集器下（ParNew / Serial Old收集器组合的规则也基本一致）的内存分配和回收的策略。

对象优先在 Eden 分配

大多数情况下，对象在新生代Eden 区中分配， 当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

虚拟机提供了 -XX: + PrintGCDetails 这个收集器日志参数， 告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况，在实际应用中，内存回收日志一般时打印到文件后通过日志工具进行分析，不过本实验的日志并不多。

代码清单3-5 新生代 Minor GC

private static final int _1MB 1024 * 1024;
/**
*  VM 参数 ：  -verbose:gc - Xms20M -Xmx20M -Xmn10M -XX:+PrintGCDetails -XX:SurvivorRatio=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[2 * _1MB]; //出现一次 Mionr GC

运行结果：

代码中的 testAllocation（） 方法中，尝试分配 3 个 2MB 大小和 1 个 4MB大小的对象， 在运行时通过 -Xms20M、-Xmx20M、 -Xmn10M 这 3 个参数限制了Java堆大小为 20 MB ,不可扩展，其中 10 MB 分配给新生代，剩下的10 MB分配给老年代， -XX:SurvivorRatio = 8 决定了新生代中 Eden 区与一个 Survivor 区的空间比例时 8 ： 1， 从输出的结果也可以看到。

执行testAllocation（） 中分配 allocation4 对象的语句时会发生一次 Minor GC ，这次GC的结果时新生代 6651KB 变为 148KB， 而总内存占用量几乎没有减少（因为 allocation1、allocation2、allocation3 三个对象都是存活的，虚拟机几乎没有找到可回收的对象）， 这次 GC发生的原因时给 allocation4 分配内存的时候，发现 Eden 已经被占用了 6MB， 剩余空间已不足以分配 allocation4 所需的 4MB 内存，因此发生 Minor GC。 GC期间虚拟机又发现已有的 3 个 2MB 大小的对象全部无法放入 Survivor 空间（Survivor空间只有 1 MB大小）所以只好通过分配担保机制提前转移到老年代。

这次GC结束后，4MB的 allocation4 对象顺利分配在 Eden 中，因此程序执行完的结果时 Eden 占用 4 MB（被allocation4 占用）。通过 GC日志可以证实这一点。

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

3.6.2 大对象直接进入老年代

所谓的大对象是指， 需要大量连续内存空间的Java对象， 最典型的大对象就是那种很长的字符串以及数组，大对象对虚拟机的内存分配来说就是一个坏消息（比遇到一个大对象更惨的是遇到一群“朝生夕灭 ” 是短命大对象，写程序的时候尽量避免），经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续空间来“安置” 它们。

虚拟机提供了一个 -XX:PretenureSize Threshold参数，令大于这个设置值的对象直接在老年代分配，避免在 Eden 区及两个 Survivor 区之间法神大量的复制。

代码清单3-6 大对象直接进入老年代

private static final int _1MB = 1024 * 1024;

/**
* VM 参数 ；-verbose:gc -XMs20M -Xmx20M -Xmn10M -XX:+ PrintGCDetails -XX：SurvivorRatio =8。
*  -XX: PretenureSizeThreshold = 3145728
*/
public static void testPretenureSizeThreshold(){
	byte[] allocation;
	allocation = new byte[4 * _1MB]; //直接分配在老年代中。
}

执行了上述代码的 testPretenureSizeThreshold() 方法后，我们看到 Eden空间几乎没有被使用，而老年代的 10MB空间被使用了40 %， 也就是 4 MB的 allocation 对象直接就分配在老年代中，这是因为 PretenureSizeThreshold 被设置为 3 MB（就是 31545728,这个参数不能直接写 3MB），因此超过 3 MB 的对象就会直接在老年代进行分配。

注意 PretenureSizeThreshold参数只对 Serial 和 ParNew 两款收集器有效， Parallel Scavenge 收集器不认识这个参数，一般也不需要这个设置，如果遇到必须使用此参数的组合，可以考虑 ParNew 加 CMS 的收集器组合。

助于理解

来源：https://www.iteye.com/blog/lhc1986-1421832
jvm区域总体分两类，heap区和非heap区。heap区又分：Eden Space（伊甸园）、Survivor Space(幸存者区)、Tenured Gen（老年代-养老区）。 非heap区又分：Code Cache(代码缓存区)、Perm Gen（永久代）、Jvm Stack(java虚拟机栈)、Local Method Statck(本地方法栈)。

HotSpot虚拟机GC算法采用分代收集算法：

有钱（表示经过程序的运行引用依然存在，即还有用）
1、一个人（对象）出来（new 出来）后会在Eden Space（伊甸园）无忧无虑的生活，直到GC到来打破了他们平静的生活。GC会逐一问清楚每个对象的情况，有没有钱（此对象的引用）啊，因为GC想赚钱呀，有钱的才可以敲诈嘛。然后富人就会进入Survivor Space（幸存者区），穷人的就直接kill掉。

2、并不是进入Survivor Space（幸存者区）后就保证人身是安全的，但至少可以活段时间。GC会定期（可以自定义）会对这些人进行敲诈，亿万富翁每次都给钱，GC很满意，就让其进入了Genured Gen(养老区)。万元户经不住几次敲诈就没钱了，GC看没有啥价值啦，就直接kill掉了。

3、进入到养老区的人基本就可以保证人身安全啦，但是亿万富豪有的也会挥霍成穷光蛋，只要钱没了，GC还是kill掉。

分区的目的：新生区由于对象产生的比较多并且大都是朝生夕灭的，所以直接采用复制算法。而养老区生命力很强，则采用标记-清理算法，针对不同情况使用不同算法。

非heap区域中Perm Gen中放着类、方法的定义，jvm Stack区域放着方法参数、局域变量等的引用，方法执行顺序按照栈的先入后出方式。

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

既然虚拟机采用了分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应放在新生代，哪些对象应放在老年代。为了做到这一点，虚拟机给每个对象定义了个对象年龄（Age）计数器。

如果对象在 Eden 出生并经过第一次 Minor GC 后仍然存活，并且能被 Survivor 容纳的话，将被移动到 Survivor空间中，并且对象年龄设定为 1，对象在 Survivor 区中每“熬过”一次 Minor GC ,年龄就增加一岁，当它的年龄增加到一定程度（默认为15岁），就会被晋升到老年代中，对象晋升老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 设置。

3.6.4 动态对象年龄判定

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

3.6.5 空间分配担保

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

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

从这里我们也可以看出，取平均值还是有一定风险的，毕竟出现高于平均值的情况也不是不可能， 这样的话依然会导致担保失败， 那只能之后再来一次 Full GC ,这样后续会很麻烦，但是一般还是要打开担保的，毕竟可以避免 Full GC 过于频繁。