1.躲过15次GC之后进入老年代

系统刚启动时，创建的各种各样的对象，都是分配在年轻代里。

随着慢慢系统跑着跑着，年轻代满了，就会出发Minor GC ，可能1%的少量存活对像转移到空着的Survivor区中

然后系统继续运行，继续在Eden区里分配对象........

.....

类似静态变量等引用的对象，可能存活时间会久一些，无论年轻代中怎么垃圾回收，类似这种对象都不会被回收掉。

而此对象每次在年轻代里躲过一次Minor GC被转移到一块Survivor区域中，他的年龄就会增加一岁

默认的设置下，当对象的年龄达到15岁时，也就是躲过15次GC的时候，他就会转移到老年代里去。

 

具体是多少岁进入老年代，可以通过JVM参数“-XX:MaxTenuringThreshold”来设置，默认是15岁

 

2.动态对象年龄判断

 

这里跟这个对象年龄有另外一个规则可以让对象进入老年代，不用等到15次GC过后才可以。

 

他的大致规则就是，假如说当前放对象的Survivor区域里，一批对象的总大小大于了这块Survivor区域的内存大小的50%，那么此时大于等于这批对象年龄的对象，就可以直接进入老年代了。

假设这个图中的Survivor2区有两个对象，这俩对象的年龄一样，都是2岁

然后俩对象加起来内存超过了50MB，这个时候，Survivor2区里大于等于2岁的对象，都要进入老年代里去。

这就是动态年龄判断的规则，这条规则也会让一些年轻代的对象进入老年代

另外实际这个规则运行的时候是如下的逻辑：年龄1+年龄2+年龄n的多个年龄对象总和超过了Survivor区的50%，此时就会把年龄n以上的对象都放入老年代。

 

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

 

有一个JVM参数，就是“-XX:PretenureSizeThreshold”，可以把它的值设置为字节数，比如“1048576”字节，就是1MB

意思就是如果你要创建一个大于这个大小的对象，比如一个超大的数组，或者是别的啥东西，此时就直接把这个大对象放到老年代里去，压根不会经过年轻代。

之所以这么做，是因为要避免年轻代里出现那种大对象，然后屡次躲过GC，还得把他在两个Survivor区域里来回复制多次之后才能进入老年代。

所以说这也是一个对象进入老年代的规则

 

4.Minor GC后的对象太多，无法放入Survivor区

如图所示：

这个时候就必须得把这些对象直接转移到老年代去！

5.老年代空间分配担保规则

如果年轻代里大量对象存活，确实自己的Survivor区放不下了，必须转移到老年代去

但是如果老年代里空间也不够放这些对象，改怎么办呢？

 

首先，在执行任何一次Minor GC之前，JVM都会先检查一些老年代可用的内存空间，是否大于年轻代所有对象的总大小

问什么呢？因为最极端的情况下，可能年轻代Minor GC之后，所有对象都存活下来了，那岂不是年轻代所有对象全部进入老年代

如果说发现老年代内存大小是大于年轻代所有对象的，此时就可以放心大胆地对年轻代发起一次Minor GC了。

 

但是假如执行Minor GC之前，发现老年代的可用内存已经小于了年轻代的全部对象大小了

恰好这个时候Minor GC之后年轻代的对象全部存活下来，全部需要转移到老年代中去，但是老年代内存空间又不够？

 

所以假如Minor GC之前，发现老年代的可用内存已经小于了年轻代的全部对象大小，就会看一个“-XX:-HandlePromotionFailure”的参数是否设置了

如果有这个参数，那么就会看看老年代的内存大小，是否大于之前每一次Minor GC后进去老年代对象的平均大小

 

但是如果上面步骤判断失败了，或者是“-XX:-HandlePromotionFailure”参数没设置，此时就会直接触发一次“Full GC”，

就是对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC。

 

如果上面两个步骤判断成功，那么就可以尝试Minor GC，此时进行Minor GC有几种可能：

①Minor GC过后，剩余的存活对象的大小，小于Survivor区的大小，那么此时存活对象进入Survivor区即可

②Minor GC过后，剩余的存活对象的大小，大于Survivor区的大小，但是小于老年代可用内存大小，就直接进入老年代即可

③Minor GC过后，剩余的存活对象的大小，大于Survivor区的大小，同时大于老年代可用内存大小，此时就会发生“Handle Promotion Failure”的情况，这个时候就会出发一次“Full GC”。

 

Full GC就是对老年代进行垃圾回收，同时也一般会对年轻代进行垃圾回收。

 

如果Full GC之后，老年代还是没有足够空间存放Minor GC过

当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中。分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存 划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young  Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃 圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。那什么情况下对象会从新生代进入到老年代呢？

目前大部分的JVM的GC对于新生代都采用的是复制算法，因为新生代中每次垃圾回收都要 回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代 划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用 Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另 一块 Survivor 空间中。

而老年代因为每次只回收一小部分的对象，所以采用的是标记-复制算法。

对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目 前存放对象的那一块)，少数情况会直接分配到老生代。当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden  Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From  Space 进行清理。如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。 在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。

以上是我理解的新生代和老年代的转换。

顺带提一嘴，在JDK1.8之后，将之前的“永久代”改为“元空间”了，这两者我觉得其实就是对方法区的一种实现。后者也弥补了前者的一些缺点，这里就不提了。

分代回收

我们从一个object1来说明其在分代垃圾回收算法中的回收轨迹。

1、object1新建，出生于新生代的Eden区域。

2、minor GC，object1 还存活，移动到Fromsuvivor空间，此时还在新生代。

3、minor GC，object1 仍然存活，此时会通过复制算法，将object1移动到ToSuv区域，此时object1的年龄age+1。

4、minor GC，object1 仍然存活，此时survivor中和object1同龄的对象并没有达到survivor的一半，所以此时通过复制算法，将fromSuv和Tosuv 区域进行互换，存活的对象被移动到了Tosuv。

5、minor GC，object1 仍然存活，此时survivor中和object1同龄的对象已经达到survivor的一半以上（toSuv的区域已经满了），object1被移动到了老年代区域。

6、object1存活一段时间后，发现此时object1不可达GcRoots，而且此时老年代空间比率已经超过了阈值,触发了majorGC（也可以认为是fullGC，但具体需要垃圾收集器来联系），此时object1被回收了。fullGC会触发 stop the world。

在以上的新生代中，我们有提到对象的age，对象存活于survivor状态下，不会立即晋升为老生代对象，以避免给老生代造成过大的影响，它们必须要满足以下条件才可以晋升：

1、minor gc 之后，存活于survivor 区域的对象的age会+1，当超过（默认）15的时候，转移到老年代。

2、动态对象，如果survivor空间中相同年龄所有的对象大小的综合和大于survivor空间的一半，年级大于或等于该年级的对象就可以直接进入老年代。

以上采用分代垃圾收集的思想，对一个对象从存活到死亡所经历的历程。期间，在新生代的时刻，会用到复制算法，在老年代时，有可能会用到标记-清楚算法（mark-sweep）算法或者标记-整理算法，这些都是垃圾回收算法基于不同区域的实现，我们看下这几种回收算法的实现原理。

当对象在 Survivor 区躲过一次 GC 后，其年龄就会+1。默认情况下年龄到达 15 的对象会被移到老生代中。分代收集法是目前大部分 JVM 所采用的方法，其核心思想是根据对象存活的不同生命周期将内存 划分为不同的域，一般情况下将 GC 堆划分为老生代(Tenured/Old Generation)和新生代(Young  Generation)。老生代的特点是每次垃圾回收时只有少量对象需要被回收，新生代的特点是每次垃 圾回收时都有大量垃圾需要被回收，因此可以根据不同区域选择不同的算法。那什么情况下对象会从新生代进入到老年代呢？

目前大部分的JVM的GC对于新生代都采用的是复制算法，因为新生代中每次垃圾回收都要 回收大部分对象，即要复制的操作比较少，但通常并不是按照 1：1 来划分新生代。一般将新生代 划分为一块较大的 Eden 空间和两个较小的 Survivor 空间(From Space, To Space)，每次使用 Eden 空间和其中的一块 Survivor 空间，当进行回收时，将该两块空间中还存活的对象复制到另 一块 Survivor 空间中。

而老年代因为每次只回收一小部分的对象，所以采用的是标记-复制算法。

对象的内存分配主要在新生代的 Eden Space 和 Survivor Space 的 From Space(Survivor 目 前存放对象的那一块)，少数情况会直接分配到老生代。当新生代的 Eden Space 和 From Space 空间不足时就会发生一次 GC，进行 GC 后，Eden  Space 和 From Space 区的存活对象会被挪到 To Space，然后将 Eden Space 和 From  Space 进行清理。如果 To Space 无法足够存储某个对象，则将这个对象存储到老生代。 在进行 GC 后，使用的便是 Eden Space 和 To Space 了，如此反复循环。