JVM : 13 面试题：年轻代和老年代分别适合什么样的垃圾回收算法？

水深无声 2022-09-11 00:04 212阅读 0赞

### 1. 新生代里的对象一般在什么场景下会进入老年代？ ###

代码在运行的过程中，会不断的创建各种各样的对象，这些对象都会优先放到新生代的 Eden区和 Survivor1区。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_15_color_FFFFFF_t_70_g_se_x_16][]

接着假如新生代的 Eden区和 Survivor1区都快满了，此时就会触发Minor GC，把存活对象转移到 Survivor2区去。如下图所示：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_15_color_FFFFFF_t_70_g_se_x_16 1][]

然后接着会使用 Eden区和Survivor2区，来分配新的对象，如下图所示：

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_14_color_FFFFFF_t_70_g_se_x_16][]

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

在上面的流程中，随着系统的运行，新生代逐渐满了，就会触发Minor GC，此时就有少量的存活对象转移到空着的Survivor区中。

然后系统机型运行，继续在Eden区里分配各种对象。

部分强引用对象每次在新生代里躲过一次GC被转移到一块Survivor区域中，此时他的年龄就会增长一岁。

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

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

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16][]

### 3. 动态对象年龄判断 ###

除了对象年龄规则外，还有其他规则可以让对象进入老年代，不用等待15次GC过后才可以。

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

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 1][]

案例说明，假设这个图里的Survivor2区有两个对象，这两个对象的年龄一样都是2岁，且两对象加起来超过了50MB，也就是Survivor2区的50%。那么这时候，Survivor2区里的大于等于2的对象，就要全部进入老年代里去。

这就是所谓的**动态年龄判断**的规则，这条规则也会让一些新生代的对象进入老年代。

###  4. 大对象直接进入老年代 ###

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

它的意思是，如果你创建了一个大于这个值大小的对象，比如数组或集合，就会直接把这个大对象放到老年代里去。而不会经过新生代。

这么做，是为了避免新生代出现大对象后，频繁进行GC回收复制后才能进入老年代。这样会很耗费时间和导致频繁GC。

### 5. Minor GC后的对象太多无法放入 Survivor区怎么办？ ###

如果在Minor GC之后发现剩余的存活对象太多了，没办法放入另外一块 Survivor 区，就会直接把这些**对象直接转移到老年代去**。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 2][]

如上图，Eden区剩余150MB对象，会直接放入到老年代。

### 6. 老年代空间分配担保原则 ###

如果新生代有大量对象存活下来，Survivor区内存不够放不下了，必须转移到老年代去。如果此时老年代里空间也不够放这些对象，该怎么办？

首先，在执行Minor GC之前，JVM会先检查一下老年代可用的内存空间，是否大于新生代所有对象的总大小。

该检查，是为了**保证极端环境下，新生代Minor GC过后存活下来要转移到老年代的所有对象都能转移到老年代里**。

![watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 3][]

如果发现**老年代的内存大小是大于新生代所有对象的**，就可以对新生代进行Minor GC了。即使Minor GC之后所存活的对象在Survivor区放不下，也可以转移到老年代去。

如果执行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过后的剩余存活对象，那么此时就会导致所谓的 “OOM” 内存溢出了。

### 7. 老年代垃圾回收算法 ###

简单来说，对老年代触发垃圾回收的时机，一般就是两个：

要么在Minor GC之前，通过检测发现很可能Minor GC之后要进入老年代的对象太多，老年代放不下，此时需要提前触发 Full GC然后再带着进行 Minor GC。

要么在Minor GC之后，发现剩余对象太多放入老年代都放不下了。

这里对老年代进行垃圾回收采用的是 **标记整理算法**。

所谓标记整理算法，就是先标记出来老年代当前存活的对象；接着让这些存活对象在内存里进行移动，把存活对象尽量都挪动到一边去，让存活对象紧凑的靠在一起，避免垃圾回收过后出现过多的内存碎片。

然后再一次性把垃圾对象都回收掉。

要注意的是，老年代的垃圾回收算法的速度至少比新生代的垃圾回收算法的速度**慢10倍**。

如果系统频繁出现老年代的 Full GC 垃圾回收，会导致系统性能被严重影响，出现频繁卡顿的情况。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_15_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/bb04e7694b8242018388d0ecae26c1db.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_15_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/8cd8a49a75e84951b84aa3fcbb65ee6e.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_14_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/fbff5aeaa21644fa91c216661313b139.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/9c48e86a388c4bceb80135e8e29f29cd.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220829/ed09df2315764f59b867406c30c96238.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220829/5ea99630e35645f18e5f2ac277e57e8a.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBA6a6A5Z-O5bCP5biF_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220829/6e123216e3244b95945e22ad04786f63.png