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

1. 经典垃圾收集器

Serial收集器

这个收集器是一个单线程工作的收集器，但它的“单线程”的意义并不仅仅是说明它只会使用一个处理器或一条收集线程去完成垃圾收集工作，更重要的是强调在它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束。“Stop The World”这个词语也许听起来很酷，但这项工作是由虚拟机在后台自动发起和自动完成的，在用户不可知、不可控的情况下把用户的正常工作的线程全部停掉，这对很多应用来说都是不能接受的。

迄今为止，它依然是HotSpot虚拟机运行在客户端模式下的默认新生

代收集器，有着优于其他收集器的地方，那就是简单而高效（与其他收集器的单线程相比），对于内存资源受限的环境，它是所有收集器里额外内存消耗（Memory Footprint）最小的；对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。Serial收集器对于运行在客户端模式下的虚拟机来说是一个很好的选择。

ParNew收集器

ParNew收集器实质上是Serial收集器的多线程并行版本，除了同时使用多条线程进行垃圾收集之外，其余的行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX：PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致，在实现上这两种收集器也共用了相当多的代码。ParNew收集器的工作过程如图

ParNew收集器除了支持多线程并行收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是不少运行在服务端模式下的HotSpot虚拟机，尤其是JDK 7之前的遗留系统中首选的新生代收集器，其中有一个与功能、性能无关但其实很重要的原因是：除了Serial收集器外，目前只有它能与CMS收集器配合工作。

ParNew收集器在单核心处理器的环境中绝对不会有比Serial收集器更好的效果，甚至由于存在线程交互的开销，该收集器在通过超线程（Hyper-Threading）技术实现的伪双核处理器环境中都不能百分之百保证超越Serial收集器。当然，随着可以被使用的处理器核心数量的增加，ParNew对于垃圾收集时系统资源的高效利用还是很有好处的。它默认开启的收集线程数与处理器核心数量相同，在处理器核心非常多（譬如32个，现在CPU都是多核加超线程设计，服务器达到或超过32个逻辑核心的情况非常

普遍）的环境中，可以使用-XX：ParallelGCThreads参数来限制垃圾收集的线程数。

在JDK 5中使用CMS来收集老年代的时候，新生代只能选择ParNew或Serial收集器中的一个。可以说直到CMS的出现才巩固了ParNew的地位，但成也萧何败也萧何，随着垃圾收集器技术的不断改进，更先进的G1收集器带着CMS继承者和替代者的光环登场。G1是一个面向全堆的收集器，不再需要其他新生代收集器的配合工作。所以自JDK 9开始，ParNew加CMS收集器的组合就不再是官方推荐的服务端模式下的收集器解决方案了。

注意 从ParNew收集器开始，后面还将会接触到若干款涉及“并发”和“并行”概念的收集器。在大家可能产生疑惑之前，有必要先解释清楚这两个名词。并行和并发都是并发编程中的专业名词，在谈论垃圾收集器的上下文语境中，它们可以理解为：

·并行（Parallel）：并行描述的是多条垃圾收集器线程之间的关系，说明同一时间有多条这样的线程在协同工作，通常默认此时用户线程是处于等待状态。

·并发（Concurrent）：并发描述的是垃圾收集器线程与用户线程之间的关系，说明同一时间垃圾收集器线程与用户线程都在运行。由于用户线程并未被冻结，所以程序仍然能响应服务请求，但由于垃圾收集器线程占用了一部分系统资源，此时应用程序的处理的吞吐量将受到一定影响。

Parallel Scavenge收集器

Parallel Scavenge收集器也是一款新生代收集器，它同样是基于标记-复制算法实现的，也是能够并行收集的多线程收集器

Parallel Scavenge收集器的目标是达到一个可控制的吞吐量，所谓吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值

如果虚拟机完成某个任务，用户代码加上垃圾收集总共耗费了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。停顿时间越短就越适合需要与用户交互或需要保证服务响应质量的程序，良好的响应速度能提升用户体验；而高吞吐量则可以最高效率地利用处理器资源，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的分析任务。

Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX：GCTimeRatio参数。

由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称作“吞吐量优先收集器”。除上述两个参数之外，Parallel Scavenge收集器还有⼀个参数-XX: +UseAdaptiveSizePolicy值得我们关注。这是⼀ 个开关参数，当这个参数被激活之后，就不需要⼈⼯指定新⽣代的⼤⼩(-Xmn)、Eden与Survivor区的⽐例( -XX: SurvivorRatio ) 、 晋升⽼年代对象⼤⼩( -XX : PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运⾏情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最⼤的吞吐量。⾃适应调节策略也是Parallel Scavenge收集器区别于ParNew收集器的⼀个重要特性。

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-整理算法。这个收

集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。如果在服务端模式下，它也可能有两种用

途：一种是在JDK 5以及之前的版本中与Parallel Scavenge收集器搭配使用[1]，另外一种就是作为CMS

收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的⽼年代版本，⽀持多线程并⾏收集，基于标记-整理算法实现。这个收集器是直到JDK 6时才开始提供的，在此之前，新⽣代的Parallel Scavenge收集器⼀直处于相当尴尬的状态，原因是如果新⽣代选择Parallel Scavenge 收集器，⽼年代除了Serial Old(PS MarkSweep)收集器以外别⽆选择，直到Parallel Old 收集器出现后，“吞吐量优先”收集器终于有了⽐较名副其实的搭配组合，在注重吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器 这个组合。

CMS收集器：

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，目前很多的Java应用集中在互联网网站或者基于浏览器B/S系统的服务端上，这类应用通常都会较为关注服务的响应速度，希望系统停顿时间尽可能短，以给用户带来良好的交互体验。CMS收集器就非常符合这类应用的需求。

它的运作过程分为四个步骤包括：

1. 初始标记 （CMS initial mark）
2. 并发标记 （CMS concurrent mark）
3. 重新标记 （CMS remark）
4. 并发清除 （CMS concurrent sweep）

其中初始标记和重新标记两个步骤仍然需要“Stop The World”.初始标记仅仅只是标记以下GC Roots能直接关联到的对象，速度很快; 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重 新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

CMS是一款优秀的收集器，它最主要的优点在名字上已经体现出来：并发收集、低停顿，一些官方公开文档里面也称之为“并发低停顿收集器”但是它还远达不到完美的程度，至少有以下三个明显的

缺点：

首先，CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。CMS默认启动的回收线程数是（处理器核心数量 +3）/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的处理器运算资源，并且会随着处理器核心数量的增加而下降。但是当处理器核心数量不足四个时，CMS对用户程序的影响就可能变得很大。如果应用本来的处理器负载就很高，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然大幅降低。

然后，由于CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现“Con-current ModeFailure”失败进而导致另一次完全“Stop The World”的Full GC的产生。在CMS的并发标记和并发清理阶段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。同样也是由于在垃圾收集阶段用户线程还需要持续运

行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。

  还有最后一个缺点，在本节的开头曾提到，CMS是一款基于“标记-清除”算法实现的收集器，如果读者对前面这部分介绍还有印象的话，就可能想到这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。为了解决这个问题，CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数（默认是开启的，此参数从JDK 9开始废弃），用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，（在Shenandoah和ZGC出现前）是无法并发的。这样空间碎片问题是解决了，但停顿时间又会变长，因此虚拟机设计者们还提供了另外一个参数-XX：CMSFullGCsBefore-Compaction（此参数从JDK 9开始废弃），这个参数的作用是要求CMS收集器在执行过若干次（数量由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理）。

Garbage First收集器

Garbage First(简称G1)收集器是垃圾收集器技术发展历史上的里程碑式的成果，它开创了收集器面向局部收集的设计思路和基于Region的内存布局形式。G1是一款主要面向服务端应用的垃圾收集器。它可以面向堆内存任 何部分来组成回收集（Collection Set，一般简称CSet）进行回收，衡量标准不再是它属于哪个分代，而 是哪块内存中存放的垃圾数量最多，回收收益最大，这就是G1收集器的Mixed GC模式。

G1开创的基于Region的堆内存布局是它能够实现这个目标的关键。虽然G1也仍是遵循分代收集理论设计的，但其堆内存的布局与其他收集器有非常明显的差异：G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region都可以根据需要，扮演新生代的Eden空间、Survivor空间，或者老年代空间。收集器能够对扮演不同角色的Region采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

Region中还有一类特殊的Humongous区域，专门用来存储大对象。G1认为只要大小超过了一个Region容量一半的对象即可判定为大对象。每个Region的大小可以通过参数-XX：G1HeapRegionSize设定，取值范围为1MB～32MB，且应为2的N次幂。而对于那些超过了整个Region容量的超级大对象，将会被存放在N个连续的Humongous Region之中，G1的大多数行为都把Humongous Region作为老年代的一部分来进行看待

虽然G1仍然保留新生代和老年代的概念，但新生代和老年代不再是固定的了，它们都是一系列区域（不需要连续）的动态集合。G1收集器之所以能建立可预测的停顿时间模型，是因为它将Region作为单次回收的最小单元，即每次收集到的内存空间都是Region大小的整数倍，这样可以有计划地避免在整个Java堆中进行全区域的垃圾收集。更具体的处理思路是让G1收集器去跟踪各个Region里面的垃圾堆积的“价值”大小，价值即回收所获得的空间大小以及回收所需时间的经验值，然后在后台维护一个优先级列表，每次根据用户设定允许的收集停顿时间（使用参数-XX：MaxGCPauseMillis指定，默

认值是200毫秒），优先处理回收价值收益最大的那些Region

将Java堆分成多个独⽴Region后，Region⾥⾯存在的跨Region引⽤对象如何解决？使⽤ 记忆集避免全堆作为GC Roots扫描，但在G1收集器上记忆集的应⽤其实要复杂很多，它 的每个Region都维护有⾃⼰的记忆集，这些记忆集会记录下别的Region指向⾃⼰的指针，并标记这些指针分别在哪些卡⻚的范围之内。G1的记忆集在存储结构的本质上是⼀种哈希表， Key是别的Region的起始地址，Value是⼀个集合，⾥⾯存储的元素是卡表的索引号。这种“双向”的卡表结构(卡表是“我指向谁”，这种结构还记录了“谁指向我”)⽐原来的卡表实现起来更复杂，同时由于Region数量⽐传统收集器的分代数量明显要多得 多，因此G1收集器要⽐其他的传统垃圾收集器有着更⾼的内存占⽤负担。根据经验，G1

⾄少要耗费⼤约相当于Java堆容量10%⾄20%的额外内存来维持收集器⼯作。

在并发标记阶段如何保证收集线程与⽤户线程互不⼲扰地运⾏？这⾥⾸先要解决的是⽤户线程改变对象引⽤关系时，必须保证其不能打破原本的对象图结构，CMS收集器采⽤增量更新算法实现，⽽G1收集器则是通过原始快照(SATB)算法来实现的。此外，垃圾收集对⽤户线程的影响还体现在回收过程中新创建对象的内存分配上，程序要继续运⾏就肯定会持续有新对象被创建，G1为每⼀个Region设计了两个名为TAMS(Top at Mark Start)的指针，把Region中的⼀部分空间划分出来⽤于并发回收过程中的新对象分配，并发回收时新分配的对象地址都必须要在这两个指针位置以上。G1收集器默认在这个地址以上的对象是被隐式标记过的，即默认它们是存活的，不纳⼊回收范围。与CMS中的“Concurrent Mode Failure”失败会导致Full GC类似，如果内存回收的速度赶不上内存分配的速度，G1收集器也要被迫冻结⽤户线程执⾏，导致Full GC⽽产⽣⻓时间“Stop The

World”。

如果我们不去计算⽤户线程运⾏过程中的动作(如使⽤写屏障维护记忆集的操作)，G1收集器的运作过程⼤致可划分为以下四个步骤:

·初始标记(Initial Marking): 仅仅只是标记⼀下GC Roots能直接关联到的对象，并且修改 TAMS指针的值，让下⼀阶段⽤户线程并发运⾏时，能正确地在可⽤的Region中分配新对 象。这个阶段需要停顿线程，但耗时很短，⽽且是借⽤进⾏Minor GC的时候同步完成 的，所以G1收集器在这个阶段实际并没有额外的停顿。

·并发标记(Concurrent Marking): 从GC Root开始对堆中对象进⾏可达性分析，递归扫 描整个堆⾥的对象图，找出要回收的对象，这阶段耗时较⻓，但可与⽤户程序并发执⾏。 当对象图扫描完成以后，还要重新处理SATB记录下的在并发时有引⽤变动的对象。

·最终标记(Final Marking): 对⽤户线程做另⼀个短暂的暂停，⽤于处理并发阶段结束后仍遗留下来的最后那少量的SATB记录。

·筛选回收(Live Data Counting and Evacuation): 负责更新Region的统计数据，对各个Region的回收价值和成本进⾏排序，根据⽤户所期望的停顿时间来制定回收计划，可以⾃由选择任意多个Region构成回收集，然后把决定回收的那⼀部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这⾥的操作涉及存活对象的移动，是必须暂停⽤户线程，由多条收集器线程并⾏完成的。

相⽐CMS，G1的优点有很多，暂且不论可以指定最⼤停顿时间、分Region的内存布局、按收益动态确定回收集这些创新性设计带来的红利，单从最传统的算法理论上看，G1也更有发展潜⼒。与CMS 的“标记-清除”算法不同，G1从整体来看是基于“标记-整理”算法实现的收集器，但从局部(两个Region之间)上看⼜是基于“标记-复制”算法实现，⽆论如何，这两种算法都意味着G1运作期间不会产⽣内存空间碎⽚，垃圾收集完成之后能提供规整的可⽤内存。这种特性有利于程序⻓时间运⾏，在程序为⼤对象分配内存时不容易因⽆法找到连续内存空间⽽提前触发下⼀次收集。

不过，G1相对于CMS仍然不是占全⽅位、压倒性优势的，从它出现⼏年仍不能在所有应⽤场景中代替CMS就可以得知这个结论。⽐起CMS，G1的弱项也可以列举出不少，如在⽤户程序运⾏过程中，G1⽆论是为了垃圾收集产⽣的内存占⽤(Footprint)还是程序运⾏时的额外执⾏负载(Overload)都要⽐CMS要⾼。

⽬前在⼩内存应⽤上CMS的表现⼤概率仍然要会优于G1，⽽在⼤内存应⽤上G1则⼤多能发挥其优势，这个优劣势的Java堆容量平衡点通常在6GB⾄8GB之间。

1. 选择垃圾收集器的权衡

衡量垃圾收集器的三项最重要的指标是: 内存占⽤(Footprint)、吞吐量(Throughput)和延迟(Latency)，三者共同构成了⼀个“不可能三⻆”。三者总体的表现会随技术进步⽽越来越好，但是要在这三个⽅⾯同时具有卓越表现的“完美”收集器是极其困难甚⾄是不可能的，⼀款优秀的收集器通常最多可以同时达成其中的两项。我们应该如何选择⼀款适合⾃⼰应⽤的收集器呢?这个问题的答案主要受以下三个因素影响:

·应⽤程序的主要关注点是什么? 如果是数据分析、科学计算类的任务，⽬标是能尽快算出结果，那吞吐量就是主要关注点; 如果是SLA应⽤，那停顿时间直接影响服务质量，严重的甚⾄会导致事务超时，这样延迟就是主要关注点; ⽽如果是客户端应⽤或者嵌⼊式应⽤，那垃圾收集的内存占⽤则是不可忽视的。

·运⾏应⽤的基础设施如何? 譬如硬件规格，要涉及的系统架构是x86-32/64、SPARC还是ARM /Aarch64; 处理器的数量多少，分配内存的⼤⼩; 选择的操作系统是Linux、Solaris还是Windows等。

·使⽤JDK的发⾏商是什么? 版本号是多少? 是ZingJDK/Zulu、OracleJDK、Open-JDK、

OpenJ9抑或是其他公司的发⾏版?该JDK对应了《Java虚拟机规范》的哪个版本?

⼀般来说，收集器的选择就从以上这⼏点出发来考虑。举个例⼦，假设某个直接⾯向⽤户提供服务的B/S系统准备选择垃圾收集器，⼀般来说延迟时间是这类应⽤的主要关注点。

1. 虚拟机及垃圾收集日志

HotSpot所有功能的⽇志都收归到了“-Xlog”参数上:

命令⾏中最关键的参数是选择器(Selector)，它由标签(Tag)和⽇志级别(Level)共同组成。

⽇志级别从低到⾼，共有Trace，Debug，Info，Warning，Error，Of六种级别，⽇志级别决定了输出信息的详细程度，默认级别为Info。

另外，还可以使⽤修饰器(Decorator)来要求每⾏⽇志输出都附加上额外的内容，⽀持附加在⽇志⾏上的信息包括:

·time:当前⽇期和时间。

·uptime:虚拟机启动到现在经过的时间，以秒为单位。

·timemillis:当前时间的毫秒数，相当于System.currentTimeMillis()的输出。

·uptimemillis:虚拟机启动到现在经过的毫秒数。

·timenanos:当前时间的纳秒数，相当于System.nanoTime()的输出。

·uptimenanos:虚拟机启动到现在经过的纳秒数。

·pid:进程ID。

·tid:线程ID。

·level:⽇志级别。

·tags: ⽇志输出的标签集。

如果不指定 ，默认值是uptime、level、tags这三个，此时⽇志输出类似于以下形式:

1. 内存分配与回收策略

对象优先在Eden分配：

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

大对象直接进入老年代：

大对象就是指需要大量连续内存空间的Java对象，HotSpot虚拟机提供了-XX：RpretenureSizeThreshold参数，指定大于该设置值的对象直接在老年代分配，这样做的目的就是避免在Eden区及两个Survivor区之间来回复制，产生大量的内存复制操作。

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

虚拟机给每个对象定义了一个对象年龄（Age）计数器，存储在对象头中。对象通常在Eden区里诞生，如果经过第一次Minor GC后仍然存活，并且能被Survivor容纳的话，该对象会被移动到Survivor空间中，并且将其对象年龄设为1岁。对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度(默认为15)，就会晋升老年代的年龄阈值，可以通过参数-XX：MaxTenuringThreshold设置。

动态对象年龄判断：

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

空间分配担保：

在发生Minor GC之前，虚拟机必须先检查⽼年代最⼤可⽤的连续空间是否⼤于新⽣代所有对象总空间，如果这个条件成⽴，那这⼀次Minor GC可以确保是安全的。如果不成⽴，则虚拟机会先查看-XX: HandlePromotionFailure参数的设置值是否允许担保失败(Handle Promotion Failure); 如果允许，那会继续检查⽼年代最⼤可⽤的连续空间是否⼤于历次晋升到⽼年代对象的平均⼤⼩，如果⼤于，将尝试进⾏⼀次Minor GC，尽管这次Minor GC是有⻛险的; 如果⼩于，或者-XX: HandlePromotionFailure设置不允许冒险，那这时就要改为进⾏⼀次Full GC。

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

JDK6 Update 24之后的规则变为只要老年代的连续空间大于新生代对象总大小或者历次晋升的平均大小，就会进行Minor GC，否则将进行Full GC。（不再使用-XX：HandlePromotionFailure参数了）