深入理解JVM的垃圾回收器和内存分配策略

一、垃圾收集器

上一篇博客主要讲了收集算法，如果说收集算法是内存回收的方法论，那么垃圾回收器就是内存回收的具体实现。以下讲的收集器基于JDK 1.7的G1收集器之后的HotSpot虚拟机，这个JVM包含的所有收集器如下图所示：

上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明他们可以搭配使用。所处的区域表示它是属于新生代收集器还是老年代收集器。再将具体的收集器之前我们需要先明确三个概念：

1. 并行(Parallel)：指多条垃圾收集线程并行工作，用户线程仍处于等待状态。
2. 并发(Concurrent)：指用户线程与垃圾收集线程同时执行(不一定并行，可能会交替执行)，用户程序继续运行，而垃圾收集程序在另一个CPU上。
3. 吞吐量：就是CPU用于运行用户代码的时间与CPU总消耗时间的比值，即吞吐量 = 运行用户代码 / (运行用户代码 + 垃圾收集时间)。如：虚拟机总共运行了100分钟，其中垃圾收集花掉了1分钟，那么吞吐量就是99%。

1.1 Serial 收集器(新生代收集器，串行GC)

Serial 收集器是最基本、发展历史最悠久的收集器，曾经(在JDK 1.3以前)是虚拟机新生代收集的唯一选择。

1. 特性：这个收集器是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束(Stop The World)。
2. 应用场景：Serial 收集器是虚拟机运行在 Client 模式下的默认新生代收集器。
3. 优势：简单而高效(与其他收集器的单线程相比)，对于限定单个CPU的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。实际上到现在为止，它依然是虚拟机运行在 Client 模式下的默认新生代收集器。
   

1.2 ParNew 收集器(新生代收集器，并行GC)

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。

1. 特性：Serial 收集器的多线程版本。

2. 应用场景：ParNew 收集器是许多运行在 Server 模式下的虚拟机中首选的新生代收集器。

   作为Server的首选收集器之中有一个与性能无关的很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。在JDK 1.5时期，HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器，这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作。不幸的是，CMS作为老年代的收集器，却无法与JDK 1.4.0中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个。

3. 对比分析：与 Serial 收集器对比，ParNew 收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。然而，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。
   

1.3 Parallel Scavenge收集器(新生代收集器,并行GC)

1. 特性：Parallel Scavenge 收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器。
   Parallel Scavenge 收集器使用两个参数控制吞吐量：
           a. XX:MaxGCPauseMillis 控制最大的垃圾收集停顿时间
           b. XX:GCRatio 直接设置吞吐量的大小。
   直观上，只要最大的垃圾收集停顿时间越小，吞吐量是越高的，但是GC停顿时间的缩短是以牺牲吞吐量和新生代空间作为代价的。比如原来10秒收集一次，每次停顿100毫秒，现在变成5秒收集一次，每次停顿70毫秒。停顿时间下降的同时，吞吐量也下降了。
2. 应用场景：停顿时间越短就越适合需要与用户交互的程序，良好的响应速度能提升用户体验，而高吞吐量则可以高效率地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
3. 对比分析：
           a. Parallel Scavenge收集器 VS CMS等收集器：
               Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集             时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量（Throughput）。
           b. Parallel Scavenge收集器 VS ParNew收集器：
               Parallel Scavenge收集器与ParNew收集器的一个重要区别是它具有自适应调节策略。
   GC自适应的调节策略：Parallel Scavenge收集器有一个参数- XX:+UseAdaptiveSizePolicy 。当这个参数打开之
   后，就不需要手工指定新生代的大小、Eden与Survivor区的比例、晋升老年代对象年龄等细节参数了，虚拟机会根
   据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调
   节方式称为GC自适应的调节策略（GC Ergonomics）。
   工作流程图同 ParNew。

1.4 Serial Old 收集器(老年代收集器，串行GC)

1. 特性：Serial Old 是 Serial 收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。
2. 应用场景：
           a. Client 模式：
               Serial Old收集器的主要意义也是在于给Client模式下的虚拟机使用。
           b. Server 模式：
               如果在Server模式下，那么它主要还有两大用途：一种用途是在JDK 1.5以及之前的版本中与ParallelScavenge收集
               器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。
   

1.5 Parallel Old 收集器(老年代收集器，并行GC)

1. 特性：Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记－整理”算法。
2. 应用场景：在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器。

这个收集器是在JDK 1.6中才开始提供的，在此之前，新生代的Parallel Scavenge收集器一直处于比较尴尬的状态。原因是，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器外别无选择（Parallel Scavenge收集器无法与CMS收集器配合工作）。由于老年代Serial Old收集器在服务端应用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大而且硬件比较高级的环境中，这种组合的吞吐量甚至还不一定有ParNew加CMS的组合“给力”。直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的应用组合。

1.6 CMS收集器(老年代收集器，并发GC)

1. 特性：CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
   CMS收集器是基于“标记—清除”算法实现的，它的运作过程相对于前面几种收集器来说更复杂一些，整个过程分为
   4个步骤：
           a. 初始标记(CMS initial mark)：初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The
               World”。
           b. 并发标记(CMS concurrent mark)：并发标记阶段就是进行GC Roots Tracing的过程。
           c. 重新标记(CMS remark)：重新标记阶段是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部
               分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短，仍然需
               要“Stop The World”。
           d. 并发清除(CMS concurrent sweep)：并发清除阶段会清除对象。
   由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
2. 优点：CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿。
3. 缺点：
   CMS收集器对CPU资源非常敏感
   其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
   CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个（譬如2个）时，CMS对用户程序的影响就可能变得很大。
   CMS收集器无法处理浮动垃圾
   CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
   CMS收集器会产生大量空间碎片
   CMS是一款基于“标记—清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。
   

1.7 G1收集器(唯一一款全区域的垃圾回收器)

G1(Garbage First) 垃圾回收器是用在 heap memory 很大的情况下，把 heap 划分很多很多大小相等的 region 块，然后并行的对其进行垃圾回收。
G1 垃圾回收器在清除实例所占用的内存空间后，还会做内存压缩。
并行与并发：G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个 CPU (CPU或者CPU核心) 来缩短 Stop The World 停顿时间， 部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 线程继续执行。
分代收集：与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次 GC 的旧对象已获得更好的收集效果。
空间整合：G1 垃圾回收器回收 region 的时候基本不会 STW，而是基于 most garbage 优先回收(整体来看是基于“标记-整理”算法，从局部(两个 region 之间)基于“复制”算法)的策略来对 region 进行垃圾回收的。无论如何，G1收集器采用的算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC。

年轻代垃圾收集
在G1垃圾收集器中，年轻代的垃圾回收过程使用复制算法。把Eden区和Survivor区的对象复制到新的Survivor区域。
如图：

老年代垃圾收集
对于老年代上的垃圾收集，G1 垃圾收集器也分为4个阶段，基本跟 CMS 垃圾收集器一样，但略有不同：

• 初始标记 (Initial Mark) 阶段- 同 CMS 垃圾收集器的Initial Mark阶段一样，G1 也需要暂停应用程序的执行，它会标记从根对象出发，在根对象的第一层孩子节点中标记所有可达的对象。但是G1的垃圾收集器的 Initial Mark 阶段是跟 minor gc 一同发生的。也就是说，在 G1 中，你不用像在 CMS 那样，单独暂停应用程序的执行来运行 Initial Mark 阶段，而是在 G1 触发 minor gc的时候一并将年老代上的Initial Mark给做了。
• 并发标记 (Concurrent Mark) 阶段- 在这个阶段 G1 做的事情跟 CMS 一样。但 G1 同时还多做了一件事情，就是如果在Concurrent Mark 阶段中，发现哪些Tenured region中对象的存活率很小或者基本没有对象存活，那么G1就会在这个阶段将其回收掉，而不用等到后面的 clean up 阶段。这也是 Garbage First 名字的由来。同时,在该阶段，G1 会计算每个region的对象存活率，方便后面的 clean up 阶段使用。
• 最终标记(CMS中的Remark阶段) - 在这个阶段G1做的事情跟CMS一样, 但是采用的算法不同，G1 采用一种叫做SATB(snapshot-at-the-begining) 的算法能够在Remark阶段更快的标记可达对象。
• 筛选回收 (Clean up/Copy) 阶段- 在 G1 中，没有 CMS 中对应的 Sweep 阶段。相反它有一个 Cleanup/Copy 阶段，在这个阶段中,G1 会挑选出那些对象存活率低的 region 进行回收，这个阶段也是和 minor gc 一同发生的,如下图所示：
  
  G1（Garbage-First）是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替换掉JDK1.5中发布的CMS收集器。如果你的应用追求低停顿，G1可以作为选择；如果你的应用追求吞吐量，G1并不带来特别明显的好处。

1.8 理解 GC 日志

每一种收集器的日志形式都是由它们自身的实现所决定的，换而言之，每个收集器的日志格式都可以不一样。但虚拟机设计者为了方便用户阅读，将各个收集器的日志都维持一定的共性，例如以下两段典型的GC日志：

[GC [DefNew: 3324K->152K(3712K), 0.0025925 secs] 3324K->152K(11904K), 0.0031680 secs]
[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K>
2999K(21248K)], 0.0150007 secs] [Times: user=0.01 sys=0.00, real=0.02 secs]

GC日志开头的“［GC”和“［Full GC”说明了这次垃圾收集的停顿类型，而不是用来区分新生代GC还是老年代GC的。如果有“Full”，说明这次GC是发生了Stop-The-World的。 例如下面这段新生代收集器ParNew的日志也会出现“［Full GC”（这一般是因为出现了分配担保失败之类的问题，所以才导致STW）。如果是调用System.gc()方法所触发的收集，那么在这里将显示“［Full GC (System)”。

[Full GC 283.736: [ParNew: 261599K->261599K(261952K), 0.0000288 secs]

接下来的“［DefNew”、“［Tenured”、“［Perm”表示GC发生的区域，这里显示的区域名称与使用的GC收集器是密切相关的，例如上面样例所使用的Serial收集器中的新生代名为“Default New Generation”，所以显示的是“［DefNew”。如果是ParNew收集器，新生代名称就会变为“［ParNew”，意为“Parallel New Generation”。如果采用Parallel Scavenge收集器，那它配套的新生代称为“PSYoungGen”，老年代和永久代同理，名称也是由收集器决定的。
后面方括号内部的“3324K->152K(3712K)”含义是“GC前该内存区域已使用容量-> GC后该内存区域已使用容量(该内存区域总容量)”。而在方括号之外的“3324K->152K(11904K)”表示“GC前Java堆已使用容量-> GC后Java堆已使用容量(Java堆总容量)”。
再往后，“0.0025925 secs”表示该内存区域GC所占用的时间，单位是秒。有的收集器会给出更具体的时间数据，如“［Times：user=0.01 sys=0.00，real=0.02 secs］”，这里面的user、sys和real与Linux的time命令所输出的时间含义一致，分别代表用户态消耗的CPU时间、内核态消耗的CPU事件和操作从开始到结束所经过的墙钟时间（Wall Clock Time）。CPU时间与墙钟时间的区别是，墙钟时间包括各种非运算的等待耗时，例如等待磁盘I/O、等待线程阻塞，而CPU时间不包括这些耗时，但当系统有多CPU或者多核的话，多线程操作会叠加这些CPU时间，所以读者看到user或sys时间超过real时间是完全正常的。

1.9 垃圾收集器参数总结

JDK 1.7 中的各种垃圾收集器到此已经全部介绍完毕，在描述过程中提到了很多虚拟机非稳定的运行参数。在下图中整理出来：

二、内存分配策略

Java 技术体系中所提倡的自动内存管理最终可以归结为自动化的解决了两个问题：给对象分配内存以及回收给对象分配的内存。关于回收内存这一点，之前已经花了大篇幅的介绍虚拟机中的垃圾收集器体系以及运作原理，现在再来探讨一下给对象分配内存那点事儿。

2.1 对象优先在 Eden 分配

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

/**
 * JVM参数如下:
 * -XX:+PrintGCDetails
 * -XX:+UseSerialGC(使用Serial+Serial Old收集器组合)
 * -Xms20M -Xmx20M -Xmn10M(设置新生代大小)
 * -XX:SurvivorRatio=8(Eden:Survivor = 8 : 1)
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;
    public static void testAllocation() {
        byte[] allocation1,allocation2,allocation3,allocation4;
        allocation1 = new byte[2 * _1MB];
        allocation2 = new byte[2 * _1MB];
        allocation3 = new byte[2 * _1MB];
        // 出现Minor GC
        allocation4 = new byte[4 * _1MB];
    }
    public static void main(String[] args) throws Exception{
        testAllocation();
    }
}

运行上述程序看到的 GC 日志如下：

[GC (Allocation Failure) [DefNew: 7316K->624K(9216K), 0.0038519 secs] 7316K->6768K(19456K),
0.0038901 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4802K [0x00000000fec00000, 0x00000000ff600000,
0x00000000ff600000)
eden space 8192K, 51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
from space 1024K, 60% used [0x00000000ff500000, 0x00000000ff59c198, 0x00000000ff600000)
to space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
tenured generation total 10240K, used 6144K [0x00000000ff600000, 0x0000000100000000,
0x0000000100000000)
the space 10240K, 60% used [0x00000000ff600000, 0x00000000ffc00030, 0x00000000ffc00200,
0x0000000100000000)
Metaspace used 2776K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 296K, capacity 386K, committed 512K, reserved 1048576K

执行allocation4 = new byte[4 * _1MB];语句会发生一次Minor GC，这次GC的结果是7316K->624K(9216K-新生代总可用空间)，而总内存占用量几乎没有减少(因为allocation1、allocation2、allocation3这三个对象都还存活，虚拟机几乎没有找到可回收对象)。这次GC发生的原因是给allocation4分配内存的时候，发现Eden已经被占用了6MB，剩余空间不足以分配allocation4所需的4MB内存。因此发生Minor GC。GC期间虚拟机又发现已有的三个2MB对象无法全部放到survivor空间(空闲的To空间只有1MB)，所以只好通过分配担保机制提前转移到老年代。
本次GC结束后，4MB的allocation4对象成功分配在Eden中；剩余的三个对象(allocation1、allocation2、allocation3)被转移到老年代。上述的GC日志可以证实这一点。

2.2 大对象直接进入老年代

所谓的大对象是指，需要大量连续空间的Java对象，最典型的大对象就是那种很长的字符串以及数组(上述代码中的byte[] 数组就是典型的大对象)。大对象对虚拟机的内存分配是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发GC以获取足够的连续空间来放置大对象。
虚拟机提供了一个-XX:PretenureSizeThreshold参数，令大于这个设置值的对象直接在老年代分配。这样做的目的在于避免Eden区以及两个Survivor区之间发生大量的内存复制(新生代采用复制算法收集内存)
范例：观察大对象直接进入老年代

/**
 * JVM参数如下:
 * -XX:+PrintGCDetails
 * -XX:+UseSerialGC(使用Serial+Serial Old收集器组合)
 * -Xms20M -Xmx20M -Xmn10M(设置新生代大小)
 * -XX:SurvivorRatio=8(Eden:Survivor = 8 : 1)
 * -XX:PretenureSizeThreshold = 3145728(此时不能写3MB)
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;
    public static void testAllocation() {
        byte[] allocation;
        allocation = new byte[4 * _1MB];
    }
    public static void main(String[] args) throws Exception{
        testAllocation();
    }
}

运行上述程序看到的 GC 日志如下：

Heap
def new generation total 9216K, used 1337K [0x00000000fec00000, 0x00000000ff600000,
0x00000000ff600000)
eden space 8192K, 16% used [0x00000000fec00000, 0x00000000fed4e438, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 4096K [0x00000000ff600000, 0x0000000100000000,
0x0000000100000000)
the space 10240K, 40% used [0x00000000ff600000, 0x00000000ffa00010, 0x00000000ffa00200,
0x0000000100000000)
Metaspace used 2774K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 296K, capacity 386K, committed 512K, reserved 1048576K

执行上述代码之后，我们看到Eden空间几乎没有被使用，而老年代的10MB空间被占用了40%，也就是4MB的allocation对象就直接分配到老年代中，因为PretenureSizeThreshold被设置为3MB，因此超过3MB的对象都会直接在老年代进行分配。

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

既然虚拟机采用分代收集的思想来管理内存，那么内存回收时就必须能识别哪些对象应该放在新生代，哪些对象应该放在老年代中。为了做到这点，虚拟机给每个对象定义了一个对象年龄(Age)计数器。如果对象在Eden出生并经过一次Minor GC后仍然存活，并且能被Survivor容纳的话，将被移动到Survivor空间中，并且把对象年龄设为1.对象在Survivor空间中每”熬过”一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15岁)，就将晋升到老年代中。对象晋升到老年代的年龄阈值，可以通过参数-XX:MaxTenuringThreshold设置。
下面我们分别设置MaxTenuringThreshold = 1 和MaxTenuringThreshold = 15来观察。
范例：长期存活的对象进入老年代

/**
 * JVM参数如下:
 * -XX:+PrintGCDetails
 * -XX:+UseSerialGC(使用Serial+Serial Old收集器组合)
 * -Xms20M -Xmx20M -Xmn10M(设置新生代大小)
 * -XX:SurvivorRatio=8(Eden:Survivor = 8 : 1)
 * -XX:MaxTenuringThreshold=1
 * -XX:+PrintTenuringDistribution
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;
    @SuppressWarnings("unused")
    public static void testAllocation() {
        byte[] allocation1,allocation2,allocation3;
        allocation1 = new byte[_1MB/4];
        // 什么时候进入老年代取决于XX:MaxTenuringThreshold的设置
        allocation2 = new byte[4 * _1MB];
        allocation3 = new byte[4 * _1MB];
        allocation3 = null;
        allocation3 = new byte[4 * _1MB];
    }
    public static void main(String[] args) throws Exception{
        testAllocation();
    }
}

此方法中的allocation1对象需要256K内存，Survivor可以容纳。当MaxTenuringThreshold = 1时，allocation1对象在第二次gc的时候进入老年代，新生代已使用的内存在第二次gc后干净的变成0k。

[GC (Allocation Failure) [DefNew: 5524K->880K(9216K), 0.0029366 secs] 5524K->4976K(19456K),
0.0029730 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [DefNew: 4976K->0K(9216K), 0.0008841 secs] 9072K->4975K(19456K),
0.0009006 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4178K [0x00000000fec00000, 0x00000000ff600000,
0x00000000ff600000)
eden space 8192K, 51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 4975K [0x00000000ff600000, 0x0000000100000000,
0x0000000100000000)
the space 10240K, 48% used [0x00000000ff600000, 0x00000000ffadbce8, 0x00000000ffadbe00,
0x0000000100000000)
Metaspace used 2775K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 296K, capacity 386K, committed 512K, reserved 1048576K

而当MaxTenuringThreshold = 15时，第二次gc后，allocation1对象还留在新生代Survivor空间，此时新生代仍然有404k占用。

2.4 动态对象的年龄判定

为了能更好的适应不同程序的内存状况，JVM并不是永远要求对象的年龄必须达到MaxTenuringThreshold才能晋升老年代，如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到MaxTenuringThreshold中要求的年龄。
范例：动态对象的年龄判定

/**
 * JVM参数如下:
 * -XX:+PrintGCDetails
 * -XX:+UseSerialGC(使用Serial+Serial Old收集器组合)
 * -Xms20M -Xmx20M -Xmn10M(设置新生代大小)
 * -XX:SurvivorRatio=8(Eden:Survivor = 8 : 1)
 * -XX:MaxTenuringThreshold=15
 *
 */
public class Test {
    private static final int _1MB = 1024 * 1024;
    @SuppressWarnings("unused")
    public static void testAllocation() {
        byte[] allocation1,allocation2,allocation3,allocation4;
        allocation1 = new byte[_1MB / 4];
        // allocation1+allocation2大于Survivor空间的一半
        allocation2 = new byte[_1MB / 4];
        allocation3 = new byte[4 * _1MB];
        allocation4 = new byte[4 * _1MB];
        allocation4 = null;
        allocation4 = new byte[4 * _1MB];
    }
    public static void main(String[] args) throws Exception{
        testAllocation();
    }
}

[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 1 (max 15)
- age 1: 1048576 bytes, 1048576 total
: 5780K->1024K(9216K), 0.0029212 secs] 5780K->5232K(19456K), 0.0029656 secs] [Times: user=0.00
sys=0.00, real=0.00 secs]
[GC (Allocation Failure) [DefNew
Desired survivor size 524288 bytes, new threshold 15 (max 15)
: 5120K->0K(9216K), 0.0009421 secs] 9328K->5232K(19456K), 0.0009580 secs] [Times: user=0.00
sys=0.00, real=0.00 secs]
Heap
def new generation total 9216K, used 4178K [0x00000000fec00000, 0x00000000ff600000,
0x00000000ff600000)
eden space 8192K, 51% used [0x00000000fec00000, 0x00000000ff014930, 0x00000000ff400000)
from space 1024K, 0% used [0x00000000ff400000, 0x00000000ff400000, 0x00000000ff500000)
to space 1024K, 0% used [0x00000000ff500000, 0x00000000ff500000, 0x00000000ff600000)
tenured generation total 10240K, used 5232K [0x00000000ff600000, 0x0000000100000000,
0x0000000100000000)
the space 10240K, 51% used [0x00000000ff600000, 0x00000000ffb1c150, 0x00000000ffb1c200,
0x0000000100000000)
Metaspace used 2776K, capacity 4486K, committed 4864K, reserved 1056768K
class space used 296K, capacity 386K, committed 512K, reserved 1048576K

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

2.5 空间分配担保

在发生Minor GC之前，虚拟机会检查老年代最大可用的连续空间是否大于新生代所有对象的总空间，

• 如果大于，则此次Minor GC是安全的
• 如果小于，则虚拟机会查看HandlePromotionFailure设置值是否允许担保失败。
  如果HandlePromotionFailure=true，那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小，如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的；如果小于或者HandlePromotionFailure=false，则改为进行一次Full GC。

上面提到了Minor GC依然会有风险，是因为新生代采用复制收集算法，假如大量对象在Minor GC后仍然存活（最极端情况为内存回收后新生代中所有对象均存活），而Survivor空间是比较小的，这时就需要老年代进行分配担保，把Survivor无法容纳的对象放到老年代。老年代要进行空间分配担保，前提是老年代得有足够空间来容纳这些对象，但一共有多少对象在内存回收后存活下来是不可预知的，因此只好取之前每次垃圾回收后晋升到老年代的对象大小的平均值作为参考。使用这个平均值与老年代剩余空间进行比较，来决定是否进行Full GC来让老年代腾出更多空间。

取平均值仍然是一种概率性的事件，如果某次Minor GC后存活对象陡增，远高于平均值的话，必然导致担保失败，如果出现了分配担保失败，就只能在失败后重新发起一次Full GC。虽然存在发生这种情况的概率，但大部分时候都是能够成功分配担保的，这样就避免了过于频繁执行Full GC。