JVM垃圾回收机制与内存回收

Posted 2020-12-26 sjxbg

暂时转于：https://blog.csdn.net/qq_27035123/article/details/72857739

垃圾回收机制

 

GC是垃圾回收机制，java中将内存管理交给垃圾回收机制，这是因为在面向对象编程中一个对象的生命周期往往无法预料，所以我们无法为每个对象指定回收时机。

 

但是我们可以采用System.gc()和Runtime.getRuntime().gc()进行请求垃圾回收，可以使用对象的finalize()对必要资源在垃圾回收之前进行处理。

 

优点：使得java程序员不需要考虑内存管理，由于垃圾回收机制，java中的对象不再有作用域的限制，只有对象的引用有作用域，可以有效的防止内存泄漏，有效的使用有限的可以使用的内存。

 

垃圾收集算法

 

1. 标记-清扫（Mark-and-sweep）—sun前期版本就是用这个技术。 原理：对于“活”的对象，一定可以追溯到其存活在堆栈、静态存储区之中的引用。这个引用链条可能会穿过数个对象层次。第一阶段：从GC roots开始遍历所有的引用，对有活的对象进行标记。第二阶段：对堆进行遍历，把未标记的对象进行清除。这个解决了循环引用的问题。 缺点：1、暂停整个应用；2、会产生内存碎片。

2. 复制（copying） 原理：为了提升效率，把内存空间划分为2个相等的区域，每次只使用一个区域。垃圾回收时，遍历当前使用区域，把正在使用的对象复制到另外一个区域。优点：不会出现碎片问题。 缺点：1、暂停整个应用。2、需要2倍的内存空间。

3. 标记-整理（Mark-Compact） 原理：第一阶段标记活的对象，第二阶段把为标记的对象压缩到堆的其中一块，按顺序放。即将所有存活的对象都向一端移动，然后直接清除掉端边界以外的内存。优点：1、避免标记扫描的碎片问题；2、避免停止复制的空间问题。 具体使用什么方法GC，Java虚拟机会进行监视，如果所有对象都很稳定，垃圾回收器的效率低的话，就切换到“标记-扫描”方式；同样，Java虚拟机会跟踪“标记-扫描”的效果，要是堆空间碎片出现很多碎片，就会切换回“停止-复制”模式。这就是自适应的技术。

4. 分代（generational collecting）—–J2SE1.2以后使用此算法 原理：基于对象生命周期分析得出的垃圾回收算法。把对象分为年轻代、年老代、持久代，对不同的生命周期使用不同的算法（2-3方法中的一个即4自适应）进行回收。

   • 新生代：每次垃圾收集都有大量对象死去，只有少量存活，就选择复制算法

   • 老年代：对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”，或者“标记-整理”算法来进行回收。

5. 自适应算法(Adaptive Collector)在特定的情况下，一些垃圾收集算法会优于其它算法。基于Adaptive算法的垃圾收集器就是监控当前堆的使用情况，并将选择适当算法的垃圾收集器。

 

设想一下，如果我们作为一个GC的话，我们会如何进行垃圾回收？就像如何将一头大象放入冰箱，我们的垃圾回收也可以分为三步来实现：

 

1. 哪些内存需要进行回收？

2. 什么时候回收？

3. 怎么进行内存回收？

 

如何判断那些内存需要回收？

 

两种熟知的方法

 

同样我们站在GC的角度思考，对象存在的意义就是为了被引用，那么利用计数器，没有被引用的对象是不是可以看作死亡了呢？

 

引用计数法：如果有地方引用该对象，该对象的引用计数就+1，如果引用失效的话就减一。计数器为0的对象不可以被使用。

 

答案是不行的。试想一下，如果有两个对象互相引用，比如objA.instance = objB, objB.instance = objB，这个时候两个对象都不能被访问，但是互相引用导致引用计数不为0，这不就无法判定为死亡了吗？我们如果是GC，能允许这种长生不死的存在吗？肯定不。所以引用计数法并没有被采用在目前的JVM垃圾回收器中。

 

可达性分析法：如果我们将一些GC Roots对象作为起始点，从这些节点向下搜索，搜索到的路径为引用链，如果有一些对象没有任何引用链相连，那么这个对象对于GC Roots是不可达的，即使它们之间可能相互产生关联，所以将其判定为可回收对象。如下图：

 

GC Roots:

 

• 虚拟机栈（栈帧中的本地变量表）中引用的对象

• 方法区中类静态属性引用的对象

• 方法区中常量引用的对象

• 本地方法栈中JNI（即一般说的Native方法）引用的对象

 

那么什么是引用呢？

 

jdk1.2之前，定义为：如果reference类型的数据中存储的数值代表的是另一块内存的起始地址，就成为这块内存代表着一个引用。

 

那么我们好像对于那种如果希望内存足够的时候保留，不够的时候回收的对象一个十分明确的解释。

 

jdk1.2之后，扩展为：

 

• 强引用：只要存在，垃圾收集器就不会回收对象。

  Object obj = new Object();之类

• 软引用：用来描述一些还有用但是不必须的对象，系统将要发生内存溢出异常之前，将会把这些对象列入回收范围之中进行第二次回收，如果还是不够那就只能抛出内存溢出的异常了。

  SoftReference<String>s = new SoftReference<>(“我还有用但不是必须的!”);

• 弱引用：用来描述非必须对象，但是强度比弱引用更弱，被弱引用关联的对象只能生存到下一次垃圾收集发生之前，垃圾收集工作的时候，无论是否必要都会回收掉只被弱引用关联的对象。

  WeakReference<String>s = new WeakReference<String>(“我只能活到下一次垃圾收集之前”);

• 虚引用（幽灵引用或幻影引用）：一个对象是否有虚引用，与其生命周期毫无关系，也无法通过虚引用取得一个对象实例，只被虚引用的对象，随时都会被回收掉

  PhantomReference<String>ref = new PhantomReference<String>(“我只能接受死亡通知”) , targetReferenceQueue<String>);

 

不可达对象非死不可吗

 1 public class SaveSelf {
 2     public static SaveSelf instance = null;
 3 
 4     @Override
 5     protected void finalize() throws Throwable {
 6         super.finalize();
 7         System.out.println("finalize method executed!");
 8         instance = this;
 9     }
10     public void isAlive(){
11         System.out.println("I‘m alive!");
12     }
13 
14     public static void main(String[] args) {
15         instance = new SaveSelf();
16         instance = null;
17         System.gc();
18         try {
19             Thread.sleep(500);//用于等待Finalize线程执行finalize方法
20             if (instance != null){
21                 instance.isAlive();
22             }else{
23                 System.out.println("I will dead!");
24             }
25         } catch (InterruptedException e) {
26             e.printStackTrace();
27         }
28 
29         instance = null;
30         System.gc();
31         try {
32             Thread.sleep(500);
33             if (instance != null){
34                 instance.isAlive();
35             }else{
36                 System.out.println("I will dead!");
37             }
38         } catch (InterruptedException e) {
39             e.printStackTrace();
40         }
41     }
42 }

    finalize method executed!

    I’m alive!

    I will dead!

    Process finished with exit code 0

 

任何一个兑现过的finalize方法都会只被系统自动调用一次。当然finalize方法一般用来回收一些外部资源。

回收方法区

方法区也是有垃圾收集的，那么为什么会有呢？因为如果常量池中存在一个”abc”,而没有任何的String对象引用常量“abc”，那么我们需要对这个常量进行回收的。另外永久代的垃圾收集主要包括废弃常量和无用的类。

判定一个废弃常量很简单，那么如何判定一个无用的类（类对象比如Integer）呢？

• 该类的所有实例都已经被回收，也就是java堆中不存在任何该类的实例

• 加载该类的ClassLoader已经被回收

• 该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过访问该类的方法。

当然这里的是可以回收，但不一定必然回收。

HotSpot中的实现

枚举根节点

可达性分析对于时间的敏感性：可达性分析的过程必须在一个确保一致性的快照中进行–这里“一致性”的意思是指在整个分析的过程中执行系统看起来像是被冻结在某个时间点，不可以出现分析过程中对象的引用关系还在不断变化的情况，这样子分析结果的准确性就无法得到保证。这点是导致GC进行时必须停顿所有执行线程（Stop the world）的一个重要原因，即使是在号称（几乎）不会发生停顿的CMS收集器中，梅菊根结点也是必须要停顿的。

在HotSpot虚拟机中，使用了一组成为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpo就可以将对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下战和寄存器中哪些位置是引用。

安全点

HotSpot没有为每条指令都生成OopMap，因为这需要大量的内存空间，所以只是在“特定的位置”记录了这些信息，这些位置称为安全点（SafePoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点的时候才能进行暂停。

安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的–因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而长时间运行，而“长时间执行”最明显的特征就是指令序列服用，例如方法调用、循环跳转、一场跳转等，所以具有这些功能的指令才会产生Safepoint。

如何中断

1. 抢先式中断：不需要线程的执行代码主动的配合，在GC执行的时候，首先把所有线程全部中断，如果发现有线程中断的地方不再安全点上，就恢复线程，让它“跑”到安全点上。
2. 主动式中断：当GC需要进行中断线程的时候，不直接对线程操作，仅仅简单的设置一个标志，所个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起，轮询标志的地方和安全点是重合的，另外再加上创建对象的时候需要分配内存的地方。

几乎没有虚拟机采用抢先式中断！

安全区域

使用安全点的方法保证了程序执行时，在不太长的时间内就会遇到可以进入GC的安全点，但是如果程序不执行的时候，比如所谓的程序不执行就是没有分配到CPU时间，即处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，“走“到安全的地方去中断挂起，JVM显然不太可能等待线程重新被分配CPU时间。

安全区域是指在一段代码片段中，引用关系不会发生改变，这个区域中的任何位置开始进行GC都是安全的，我们可以把安全区域看作是拓展了的安全点。

当线程执行到安全区域的时候，首先标识自己进入了安全区域，那样，当这段时间里JVM要发起GC的时候，就不需要管标识自己为安全区域的线程，在线程要离开安全区域时，它要检查系统是否完成了根节点枚举（或者是整个GC过程），如果要完成了，线程就继续执行，否则就必须等待直到回收过程完成并可以安全离开安全区域的信号为止。

垃圾收集器

上图展示了7种作用域不同分代的收集器，如果两个收集器之间存在连线，就说明他们可以搭配使用，虚拟机所处的区域，则表示它是属于新生代收集器还是老年代收集器。

1. Serial(串行GC)收集器

Serial收集器是一个新生代收集器，单线程执行，使用复制算法。它在进行垃圾收集时，必须暂停其他所有的工作线程(用户线程)。是Jvm client模式下默认的新生代收集器。对于限定单个CPU的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

2. ParNew(并行GC)收集器

ParNew收集器其实就是serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为与Serial收集器一样。在单CPU工作环境内绝对不会有比Serial的收集器有更好的效果，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的，它默认开启的收集线程数与CPU的数量下同，在CPU非常多的环境下，可以使用-XX：ParallelGCThreads参数来限制垃圾收集的线程数。

3. Parallel Scavenge(并行回收GC)收集器

Parallel Scavenge收集器也是一个新生代收集器，它也是使用复制算法的收集器，又是并行多线程收集器。parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。吞吐量= 程序运行时间/(程序运行时间 + 垃圾收集时间)，虚拟机总共运行了100分钟。其中垃圾收集花掉1分钟，那吞吐量就是99%。Parallel Scavenge提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX：MaxGCPauseMillis参数和直接设置吞吐量大小的-XXGCTimeRatio参数。

这个收集器还有一个开关：-XX：+UseAdaptiveSizePolicy值得关注。这个开关打开后，虚拟机会根据当前系统的运行情况收集性能监控信息自动调整新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX：SurvivorRation）、晋升老年代对象大小（-XX：PretenureSizeThreshold）等细节参数。

使用自适应策略，只需要设置最大堆（-Xmx）,利用最大停顿时间或者吞吐量给虚拟机设置一个优化目标。

4. Serial Old(串行GC)收集器

Serial Old是Serial收集器的老年代版本，它同样使用一个单线程执行收集，使用“标记-整理”算法。主要使用在Client模式下的虚拟机。对于Server模式下有两个用途：1. 在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用；2. 作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

5. Parallel Old(并行GC)收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。

6. CMS(并发GC)收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。CMS收集器是基于“标记-清除”算法实现的，整个收集过程大致分为4个步骤：

①.初始标记(CMS initial mark)

②.并发标记(CMS concurrenr mark)

③.重新标记(CMS remark)

④.并发清除(CMS concurrent sweep)

其中初始标记、重新标记这两个步骤任然需要停顿其他用户线程。初始标记仅仅只是标记出GC ROOTS能直接关联到的对象，速度很快，并发标记阶段是进行GC ROOTS 根搜索算法阶段，会判定对象是否存活。而重新标记阶段则是为了修正并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间会被初始标记阶段稍长，但比并发标记阶段要短。
由于整个过程中耗时最长的并发标记和并发清除过程中，收集器线程都可以与用户线程一起工作，所以整体来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。
CMS收集器的优点：并发收集、低停顿

CMS收集器主要有三个显著缺点：
1. CMS收集器对CPU资源非常敏感。在并发阶段，虽然不会导致用户线程停顿，但是会占用CPU资源而导致引用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是：(CPU数量+3) / 4。虚拟机提供了一种称为“增量式并发收集器”的CMS收集器变种，可以在并发标记、清理的时候让GC线程、用户线程交替运行，尽量减少GC线程的独占资源的时间。
2. CMS收集器无法处理浮动垃圾，可能出现“Concurrent Mode Failure“，失败后而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行，伴随程序的运行自热会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在本次收集中处理它们，只好留待下一次GC时将其清理掉。这一部分垃圾称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，即需要预留足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分内存空间提供并发收集时的程序运作使用。在默认设置下，CMS收集器在老年代使用了68%的空间时就会被激活，也可以通过参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以降低内存回收次数提高性能。要是CMS运行期间预留的内存无法满足程序其他线程需要，就会出现“Concurrent Mode Failure”失败，这时候虚拟机将启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置的过高将会很容易致“Concurrent Mode Failure”失败，性能反而降低。
3. 碎片化，最后一个缺点，CMS是基于“标记-清除”算法实现的收集器，使用“标记-清除”算法收集后，会产生大量碎片。空间碎片太多时，将会给对象分配带来很多麻烦，比如说大对象，内存空间找不到连续的空间来分配不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数，用于在Full GC之后增加一个碎片整理过程，还可通过-XX:CMSFullGCBeforeCompaction参数设置执行多少次不压缩的Full GC之后，跟着来一次碎片整理过程。

7. G1收集器

G1(Garbage First)收集器是JDK1.7提供的一个新收集器，G1收集器基于“标记-整理”算法实现，也就是说不会产生内存碎片。还有一个特点之前的收集器进行收集的范围都是整个新生代或老年代，而G1将整个Java堆(包括新生代，老年代)。

G1收集器的特点：

1. **并行与并发：**G1利用多CPU、多核环境下的硬件优势，缩小stop-the-world的时间。
2. **分代收集：**G1不需要其他收集器配合就可以独立管理整个GC堆，但它能够采用不同的方式来处理。
3. 空间整合：整体上是“标记-整理”，局部上是基于“复制”的算法来实现的
4. 可预测的停顿：降低停顿时间，G1建立了可预测的停顿时间模型，能让使用者明确的指定在一个长度M毫秒内的时间片段，消耗在垃圾收集的时间不得超过N毫秒，这已经适实时java（RTSJ）的垃圾收集器的特征了

G1收集的步骤：

1. 初始标记
2. 并发标记
3. 最终标记
4. 筛选回收

理解GC日志

GC日志格式：

GC发生的时间 + GC的类型（GC/Full GC） + GC发生的区域（收集器决定的名称） + GC前java堆已使用容量 -> GC后java堆已使用容量（java堆总容量） +　GC所占用的时间（秒）如：[Times : user = 0.01 sys = 0.00 real = 0.02 secs] 分别表示用户态消耗的时间，内核态消耗的时间和操作从开始到结束所经过的墙钟时间。

垃圾收集器参数总结

参数	描述
-XX:+UseSerialGC	Jvm运行在Client模式下的默认值，打开此开关后，使用Serial + Serial Old的收集器组合进行内存回收
-XX:+UseParNewGC	打开此开关后，使用ParNew + Serial Old的收集器进行垃圾回收
-XX:+UseConcMarkSweepGC	使用ParNew + CMS + Serial Old的收集器组合进行内存回收，Serial Old作为CMS出现“Concurrent Mode Failure”失败后的后备收集器使用。
-XX:+UseParallelGC	Jvm运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge + Serial Old的收集器组合进行回收
-XX:+UseParallelOldGC	使用Parallel Scavenge + Parallel Old的收集器组合进行回收
-XX:SurvivorRatio	新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Subrvivor = 8:1
-XX:PretenureSizeThreshold	直接晋升到老年代对象的大小，设置这个参数后，大于这个参数的对象将直接在老年代分配
-XX:MaxTenuringThreshold	晋升到老年代的对象年龄，每次Minor GC之后，年龄就加1，当超过这个参数的值时进入老年代
-XX:UseAdaptiveSizePolicy	动态调整java堆中各个区域的大小以及进入老年代的年龄
-XX:+HandlePromotionFailure	是否允许新生代收集担保，进行一次minor gc后, 另一块Survivor空间不足时，将直接会在老年代中保留
-XX:ParallelGCThreads	设置并行GC进行内存回收的线程数
-XX:GCTimeRatio	GC时间占总时间的比列，默认值为99，即允许1%的GC时间，仅在使用Parallel Scavenge 收集器时有效
-XX:MaxGCPauseMillis	设置GC的最大停顿时间，在Parallel Scavenge 收集器下有效
-XX:CMSInitiatingOccupancyFraction	设置CMS收集器在老年代空间被使用多少后出发垃圾收集，默认值为68%，仅在CMS收集器时有效，-XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSCompactAtFullCollection	由于CMS收集器会产生碎片，此参数设置在垃圾收集器后是否需要一次内存碎片整理过程，仅在CMS收集器时有效
-XX:+CMSFullGCBeforeCompaction	设置CMS收集器在进行若干次垃圾收集后再进行一次内存碎片整理过程，通常与UseCMSCompactAtFullCollection参数一起使用
-XX:+UseFastAccessorMethods	原始类型优化
-XX:+DisableExplicitGC	是否关闭手动System.gc
-XX:+CMSParallelRemarkEnabled	降低标记停顿
-XX:LargePageSizeInBytes	内存页的大小不可设置过大，会影响Perm的大小，-XX:LargePageSizeInBytes=128m

Client、Server模式默认GC

新生代GC方式	老年代和持久	代	GC方式
	Client	Serial 串行GC	Serial Old 串行GC
	Server	Parallel Scavenge 并行回收GC	Parallel Old 并行GC

Sun/OracleJDK GC组合方式

新生代GC方式	老年代和持久	代	GC方式
	-XX:+UseSerialGC	Serial 串行GC	Serial Old 串行GC
	-XX:+UseParallelGC	Parallel Scavenge 并行回收GC	Serial Old 并行GC
	-XX:+UseConcMarkSweepGC	ParNew 并行GC	CMS 并发GC 当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC
	-XX:+UseParNewGC	ParNew 并行GC	Serial Old 串行GC
	-XX:+UseParallelOldGC	Parallel Scavenge 并行回收GC	Parallel Old 并行GC
	-XX:+UseConcMarkSweepGC -XX:+UseParNewGC	Serial 串行GC	CMS 并发GC 当出现“Concurrent Mode Failure”时 采用Serial Old 串行GC

内存分配与回收策略

对象的内存分配，往大方向讲，就是在堆上分配，对象主要分配在新生代的Eden区，如果启动了本地县城分配缓存，将按照线程优先在TLAB上分配，少数情况下也可能会直接分配在老年代中，分配规则并不是百分百固定的，其细节决定于当前使用的是哪一种垃圾收集器组合，还有虚拟机中与内存相关的参数的设置。

1. 对象优先在Eden分配

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

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慢10倍以上。

2. 大对象直接进入老年代

所谓的大对象是指，需要大量连续内存空间的java对象，最典型的大对象就是那种很长的字符串以及数组，大对象对虚拟机的内存分配来说就是一个坏消息，经常出现大对象容易导致内存还有不少空间时就提前触发垃圾收集以获取足够的连续时间来“安置”它们。虚拟机提供了-XX：PretenureSizeThreshold参数，令大于这个设置值的对戏那个直接在老年代分配，这样做的目的是避免在Eden区以及Survivor区之间发生大量的内存复制。

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

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

虚拟机为了采用分代收集的思想来管理内存，利用每个对象定义的对象年龄（Age）计数器，如果对象在Eden出生并经历了第一次Minor GC后仍然存活，并且能被Survivor接纳的话，将移动到Survivor空间中，并且对象年龄设为1，对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当他的年龄增加到一定的程度（默认为15岁），就会被晋升到老年代，对象晋升到老年代的年龄阀值，可以通过参数-XX：MaxTenuringThreshold设置。

4. 动态对象年龄判定

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

5. 空间分配担保

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

冒险：前面提到过，新生代使用复制收集算法，但为了内存利用率，只是用其中一个Survivor空间来作为轮换备份，因此当出现大量对象在Minor GC后仍然存活的情况（最极端的情况就是内存回收后新生代中所有对象都存活），就需要老年代进行分配担保，把Survivor无法容纳的对象直接进入老年代。

取平均值进行比较其实仍然是一种动态概率的手段，也就是说，如果某次Minor GC存活后的对象突增，远远高于平均值的话，依然会导致担保失败，如果发生了担保失败，那就治好在失败后重新发生一次Full GC，虽然担保失败的时候绕的圈子是最大的，但大部分的时候还是会打开分配担保的，避免Full GC过于频繁。