面试官：看你简历上写了熟悉JVM垃圾回收机制，那说说你了解的GC

最新推荐文章于 2024-04-15 20:49:44 发布

局外人Inside

最新推荐文章于 2024-04-15 20:49:44 发布

阅读量581

点赞数 1

分类专栏： Java jvm 文章标签： java 开发语言面试

本文链接：https://blog.csdn.net/weixin_42189550/article/details/123377189

版权

Java 同时被 2 个专栏收录

22 篇文章 0 订阅

订阅专栏

jvm

6 篇文章 0 订阅

订阅专栏

1. 介绍一下垃圾回收机制：

        当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”（GenerationalCollection）的理论进行设计，分代收集名为理论，实质是一套符合大多
   数程序运行实际情况的经验法则，它建立在两个分代假说之上：
       1）弱分代假说（Weak Generational Hypothesis）：绝大多数对象都是朝生夕灭的。
       2）强分代假说（Strong Generational Hypothesis）：熬过越多次垃圾收集过程的对象就越难以消亡。
   这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则：收集器应该将Java堆划分出不同的区域，然后将回收对象依据其年龄
   （年龄即对象熬过垃圾收集过程的次数）分配到不同的区域之中存储。把分代收集理论具体放到现在的商用Java虚拟机里，设计者一般至少会把Java堆划分
   为新生代（Young Generation）和老年代（Old Generation）两个区域。顾名思义，在新生代中，每次垃圾收集时都发现有大批对象死去，而每次回收后
   存活的少量对象，将会逐步晋升到老年代中存放。
       然而分代收集并非只是简单划分一下内存区域那么容易，它至少存在一个明显的困难：对象不是孤立的，对象之间会存在跨代引用。
   假如要现在进行一次只局限于新生代区域内的收集，但新生代中的对象是完全有可能被老年代所引用的，为了找出该区域中的存活对象，不得不在固定的
   GC Roots之外，再额外遍历整个老年代中所有对象来确保可达性分析结果的正确性，反过来也是一样。遍历整个老年代所有对象的方案虽然理论上可行，
   但无疑会为内存回收带来很大的性能负担。为了解决这个问题，就需要对分代收集理论添加第三条经验法则：
       3）跨代引用假说（Intergenerational Reference Hypothesis）：跨代引用相对于同代引用来说仅占极少数。
       依据这条假说，我们就不应再为了少量的跨代引用去扫描整个老年代，也不必浪费空间专门记录每一个对象是否存在及存在哪些跨代引用，
   只需在新生代上建立一个全局的数据结构（称为“记忆集”，RememberedSet），这个结构把老年代划分成若干小块，标识出老年代的哪一块内存会存在跨代
   引用。此后当发生Minor GC时，只有包含了跨代引用的小块内存里的对象才会被加入到GC Roots进行扫描。虽然这种方法需要在对象改变引用关系
   （如将自己或者某个属性赋值）时维护记录数据的正确性，会增加一些运行时的开销，但比起收集时扫描整个老年代来说仍然是划算的。

2. GC完整流程知道吗？介绍一下

前言：新创建的对象一般会被分配在新生代中，常用的新生代垃圾回收器是ParNew垃圾回收器，它按照8:1:1将新生代分成Eden、survivor0和survivor1区，这个比值可以通过修改jvm的参数-XX:SurvivorRatio来设置，默认值为8。

流程： 某一时刻当创建的对象将Eden区全部挤满，就会触发Minor GC，在正式开始Minor GC之前，JVM会先检查新生代中对象大小，是否比老年代剩余空间大。
做这个检查的原因：假如进行Minor GC之后新生代对象全部存活，新生代的survivor区放不下存活的对象，这些对象就会尝试全部放入老年代，所以要提取检查
老年代剩余空间是否够用；这个时候就有两种情况：

老年代剩余空间大于新生代对象的大小，直接进行Minor GC,即使GC完survivor区放不下，老年代也能放下。
老年代剩余空间小于新生代对象的大小，这个时候就要根据JVM是否启用了”老年代空间分配担保规则“了，可以通过查看jvm的参数：-XX:-HandlePromotionFailure来确定是否开启。

老年代空间分配担保规则是指：如果老年代剩余空间大小大于历次Minor GC之后新生代剩余对象的平均大小，那就允许进行Minor GC。因为从概率上来看，以前Minor GC后能放下，这次也可以，于是也分两种情况：

老年代剩余空间大小，大于历次Minor GC之后新生代剩余对象的平均大小，直接进行Minor GC；
老年代剩余空间大小，小于历次Minor GC之后新生代剩余对象的平均大小，先进行Full GC，把老年代回收过后再检查；

但是开启老年代空间分配担保规则也只能是从概率上说明Minor GC之后新生代对象能够放到老年代，所以也会有三种结果：

Minor GC之后的对象survivor区能够放下，直接结束GC；
Minor GC之后的对象survivor区放不下，接着进入到老年代，老年代能放下，结束GC；
Minor GC之后的对象survivor区放不下，接着进入到老年代，老年代也放不下，开始Full GC，然后再重新尝试放入老年代，如果老年代依然放不下，就只能报OOM了；

如果老年代剩余空间小于新生代对象的大小，且没有开启老年代空间分配担保机制，则进行Full GC，如果GC后的老年代仍然放不下剩余对象，报OOM；

3. GC的四种算法有过了解吗？介绍一下

1. 标记-清除
           分为标记和清除两个阶段，在标记阶段标记出所有需要回收的对象；标记完成后，在清除阶段统一回收掉所有被标记的对象。
           缺点：
               a）执行效率不稳定，当堆中包含大量对象且其中大量对象都是需要被回收的时候，必须进行大量标记和清除的动作，导致两个过程的执行效率都很低；
               b）标记清除之后会产生大量不连续的碎片化内存空间，空间碎片太多可能会导致程序在运行过程中需要分配较大对象时无法找到足够的连续内存而不得不提前触发
               一次垃圾收集动作。
2. 标记-复制
           将内存按容量划分为大小相等的两块，每次只使用其中的一块。在这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。
           缺点：
               a）如果内存中多数对象是存活的，将会产生大量的内存间复制开销；
               b）可用内存缩小为原来的一半，空间浪费较大
           优点：回收时针对整个半区进行内存回收，不用考虑空间碎片的复杂情况，只需要移动堆顶指针，按顺序分配即可，运行高效。
           扩展：
               在1989年，Andrew Appel针对具备“朝生夕灭”特点的对象，提出了一种更优化的半区复制分代策略，现在称为“Appel式回收”。 Appel式回收的具体做法是把新生代分为一块较大的Eden空间和两块较小的Survivor空间，每次分配内存只使用Eden和其中一块Survivor。发生垃圾搜集时，将Eden和Survivor中仍然存活的对象一次性复制到另外一块Survivor空间上，然后直接清理掉Eden和已用过的那块Survivor空间。HotSpot虚拟机默认Eden和Survivor的大小比例是8∶1，也即每次新生代中可用内存空间为整个新生代容量的90%（Eden的80%加上一个Survivor的10%），只有一个Survivor空间，即10%的新生代是会被“浪费”的。当然，98%的对象可被回收仅仅是“普通场景”下测得的数据，任何人都没有办法百分百保证每次回收都只有不多于10%的对象存活，因此Appel式回收还有一个充当罕见情况的“逃生门”的安全设计，当Survivor空间不足以容纳一次Minor GC之后存活的对象时，就需要依赖其他内存区域（实际上大多就是老年代）进行分配担保（Handle Promotion）。
       4. 标记-整理
           针对老年代对象的存亡特征，1974年Edward Lueders提出了另外一种有针对性的“标记-整理”（Mark-Compact）算法，其中的标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向内存空间一端移动，然后直接清理掉边界以外的内存。

4. 请介绍一下常用的几款垃圾回收器

  4.1. G1（Garbage First）：
       G1是一款主要面向服务端应用的垃圾收集器，JDK 9发布之日，G1宣告取ParallelScavenge加Parallel Old组合，成为服务端模式下的默认垃圾收集器，而CMS则沦落至被声明为不推荐使用（Deprecate）的收集器。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，这也就是“Garbage First”名字的由来。这种使用Region划分内存空间，以及具有优先级的区域回收方式，保证了G1收集器在有限的时间内获取尽可能高的收集效率。
4.2. CMS（Concurrent Mark Sweep）：
       CMS收集器是一种以获取最短回收停顿时间为目标的收集器。从名字上就可以看出CMS收集器是基于标记-清除算法实现的，它的运作过程分为四个步骤，包括：
       1）初始标记
       2）并发标记
       3）重新标记
       4）并发清除
       其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。
       由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。通过下图可以比较清楚地看到CMS收集器的运作步骤中并发和需要停顿的阶段

缺点：
       1）CMS收集器对处理器资源非常敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。
       2）由于CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现“Con-current Mode Failure”失败进而导致另一次完全“Stop TheWorld”的Full GC的产生。
       3）CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大
       的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。