Java后台开发面试实战（十二）：垃圾回收

ゝ一世哀愁。 2023-07-23 12:59 31阅读 0赞

*感谢牛客网网友提供的面试经验！*

#### 对于JVM中的垃圾回收机制： ####

1.  我们首先需要**判断垃圾**，其中中心思想为判断其是否还有引用。可以使用引用计数法和root根计数法；
2.  我们对垃圾进行回收时，需要一些**垃圾回收算法**进行理论支持。包括：标记-清除，复制，标记-整理，分代收集算法。
3.  如果说垃圾回收算法是内存回收的方法论，那么**垃圾收集器**就是内存回收的具体实现。见下图，其中CMS重点了解。
4.  最后我们划分了堆内存（年轻代【一个生成区和两个幸存区】和老年代）和非堆内存（永久代），进行垃圾分类。还有两种针对不同区域实施**垃圾回收策略**，进行最大效率的回收。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70]

#### 1. 为什么要垃圾回收？ ####

随着程序的运行，**内存中存在的实例对象、变量等**信息占据的内存越来越多，如果不及时进行垃圾回收，必然会带来程序性能的下降，甚至会因为可用内存不足造成一些不必要的系统异常。

#### 2. JVM如何判定一个对象是否应该被回收？ ####

判断一个对象是否应该被回收，主要是看其是否还有引用。判断对象是否存在引用关系的方法包括引用计数法以及root根搜索方法。

1.  **引用计数法**：是一种比较古老的回收算法。原理是**此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数**。垃圾回收时，只需要收集计数为0的对象。此算法最致命的是无法处理对象间**循环引用**的问题。
2.  **root根搜索方法**：root搜索方法的基本思路就是**通过一系列可以做为root的对象作为起始点，从这些节点开始向下搜索。当一个对象到root节点没有任何引用链接时，则证明此对象是可以被回收的**。

> 1.  **什么对象会被认为会被认为是root对象?**
> 
> >  *  栈内存中引用的对象；
> >  *  方法区中静态引用和常量引用指向的对象；
> >  *  被启动类（bootstrap加载器）加载的类和创建的对象；
> >  *  Native方法中JNI引用的对象。
> 
> 1.  **何为循环引用**?
> 
> > [link][]
> 
> 1.  **“引用”是什么意思？**
> 
> > 如果reference类型的数据中存储的数值代表的是另外一块内存的起始地址，就称为这块内存代表一个引用。JDK1.2以后将引用分为强引用，软引用，弱引用和虚引用四种。
> 
> 1.  **详细说下四种“引用”？**
> 
> > **强引用**：普通存在， P p = new P()，只要强引用存在，垃圾收集器永远不会回收掉被引用的对象。  
> > **软引用**：通过SoftReference类来实现软引用，在内存不足的时候会将这些软引用回收掉。  
> > **弱引用**：通过WeakReference类来实现弱引用，每次垃圾回收的时候肯定会回收掉弱引用。  
> > **虚引用**：也称为幽灵引用或者幻影引用，通过PhantomReference类实现。设置虚引用只是为了对象被回收时候收到一个系统通知。

#### 4. 常用的垃圾收集算法有哪些？？ ####

参考网站：https://www.cnblogs.com/ghoster/p/7580729.html

1.  **标记-清除算法**（Mark-Sweep）：算法分为“标记”和“清除”两个阶段：**首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象**，之所以说它是最基本的收集算法，是因为后续的收集算法都是基于这种思路并对其不足进行改进而得到的。它的主要不足有两个：一是效率问题，标记和清除效率都不高；二是空间问题，标记清除后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后程序在运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
2.  **复制算法**(Copying)：为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，他**将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这块的内存用完了，就将还存活这的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉**。这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半，代价未免太高了一点。
3.  **标记-整理算法**(Mark-compact)：复制收集算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是如果不想浪费50%的空间就要使用额外的空间进行分配担保（Handle Promotion当空间不够时，需要依赖其他内存），以应对被使用的内存中所有对象都100%存活的极端情况，对于“标记-整理”算法，标记过程仍与“标记-清除”算法一样，但是后续步骤不是直接对可回收对象进行清理，而是**让所有的存活对象都向一端移动，然后直接清理掉端边界以外的内存**。
4.  **分代收集算法**：当前的商业虚拟机的垃圾收集都是采用“分代收集”（Generational Collection）算法，这种算法并没有什么新的思想，只是根据对象存活周期的不同将内存划分为几块。**一般是把堆划分为新生代和老年代，这样就可以根据各个年代的特点采用最适合的收集算法**。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就采用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记-清理”或者“标记-整理”算法来进行回收。

> 1.  **为什么要采用分代收集算法？**
> 
> > 分代的垃圾回收策略，是基于这样一个事实：不同的对象的生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。
> > 
> > > 详解：在 Java 程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如 Http 请求中的 Session 对象、线程、Socket 连接，这类对象跟业务直接挂钩，因此生命周期比较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String 对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。在不进行对象存活时间区分的情况下，每次垃圾回收都是对整个堆空间进行回收，花费时间相对会长，同时，因为每次回收都需要遍历所有存活对象，但实际上，对于生命周期长的对象而言，这种遍历是没有效果的，因为可能进行了很多次遍历，但是他们依旧存在。因此，分代垃圾回收采用分治的思想，进行代的划分，把不同生命周期的对象放在不同代上，不同代上采用最适合它的垃圾回收方式进行回收。
> 
> 1.  **什么是内存碎片？如何解决？**
> 
> > 由于不同 Java 对象存活时间是不一定的，因此，在程序运行一段时间以后，如果不进行内存整理，就会出现零散的内存碎片。碎片最直接的问题就是会导致无法分配大块的内存空间，以及程序运行效率降低。所以，在上面提到的基本垃圾回收算法中，“复制”方式和“标记-整理”方式，都可以解决碎片的问题。

#### 5. 常用的垃圾收集器(内部使用垃圾收集算法)有哪些？ ####

1.  **Serial 收集器**（复制算法)新生代单线程收集器，标记和清理都是单线程，优点是简单高效。
2.  **Serial Old 收集器**（标记-整理算法）老年代单线程收集器，Serial 收集器的老年代版本。
3.  **ParNew 收集器**（停止-复制算法）新生代收集器，可以认为是 Serial 收集器的多线程版本，在多核 CPU 环境下有着比 Serial 更好的表现。
4.  **Parallel Scavenge 收集器**（停止-复制算法）并行收集器，追求高吞吐量，高效利用 CPU。吞吐量一般为 99%， 吞吐量= 用户线程时间 / (用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。
5.  **Parallel Old 收集器**（停止-复制算法）Parallel Old 收集器的老年代版本，并行收集器，吞吐量优先。
6.  **CMS**(Concurrent Mark Sweep)收集器（标记-清除算法）高并发、低停顿，追求最短 GC 回收停顿时间，cpu 占用比较高，响应时间快，停顿时间短，多核 cpu 追求高响应时间的选择。CMS 是英文 Concurrent Mark-Sweep 的简称，**是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器**。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。
7.  **G1** 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First的由来。

> 1.  **CMS垃圾清除的步骤**？  
>     https://blog.csdn.net/mc90716/article/details/80158138
> 
> > 1.  初始标记：记录下直接与 root 相连的对象，暂停所有的其他线程，速度很快；
> > 2.  并发标记：同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
> > 3.  重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录。【这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短】；
> > 4.  并发清除：开启用户线程，同时 GC 线程开始对为标记的区域做清扫。
> 
> 1.  **CMS 的优缺点**？
> 
> > 主要优点：并发收集、低停顿；  
> > 主要缺点：对 CPU 资源敏感、无法处理浮动垃圾、它使用的回收算法“标记-清除”算法会导致收集>结束时会有大量空间碎片产生。
> 
> 1.  **G1 说一下**？
> 
> > **G1 可谓博采众家之长，力求到达一种完美**。它吸取了增量收集优点，把整个堆划分为一个一个等大小的区域（region）。内存的回收和划分都以region为单位；同时，它也吸取了 CMS 的特点， **把这个垃圾回收过程分为几个阶段**，分散了垃圾回收过程；而且，G1 **也认同分代垃圾回收的思想**，认为不同对象的生命周期不同，可以采取不同收集方式，因此，它也支持分代的垃圾回收。为了达到对回收时间的可预计性，G1 在扫描了 region 以后，对其中的活跃对象的大小进行排序，首先会收集那些活跃对象小的 region，以便快速回收空间（要复制的活跃对象少了），因为活跃对象小，里面可以认为多数都是垃圾，所以这种方式被称为 Garbage First（G1）的垃圾回收算法，即：**垃圾优先的回收**。

#### 6. 说下你对垃圾回收策略的理解/垃圾回收时机？ ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70 1]  
答：JVM的内存可以分为**堆内存和非堆内存**。堆内存分为**年轻代和老年代**。年轻代又可以进一步划分为**一个Eden（伊甸）区和两个Survivor（幸存）区**组成。

1.  Minor / Scavenge GC：所有对象创建在新生代的 Eden 区，当 Eden 区满后触发新生代的 Minor GC，将 Eden 区和非空闲 Survivor 区存活的对象复制到另外一个空闲的 Survivor 区中。保证一个 Survivor 区是空的，新生代 Minor GC 就是在两个 Survivor 区之间相互复制存活对象，直到 Survivor 区满为止。我们创建的对象会优先在Eden分配，如果是大对象（很长的字符串数组）则可以直接进入老年代。另外，长期存活的对象将进入老年代，每一次MinorGC（年轻代GC），对象年龄就大一岁，默认15岁晋升到老年代。
2.  Full GC：Full GC是指发生在老年代的GC，当老年代没有足够的空间时即发生Full GC，发生Full GC一般都会有一次Minor GC。对整个堆进行整理，包括 Young、Tenured 和 Perm。Full GC 因为需要对整个堆进行回收，所以比 Minor GC 要慢，因此应该尽可能减少 Full GC 的次数。在对 JVM 调优的过程中，很大一部分工作就是对于 Full GC 的调节。

#### 7. JVM常用内存调优命令： ####

JVM在内存调优方面，提供了几个常用的命令，分别为jps，jinfo，jstack，jmap以及jstat命令。分别介绍如下：

1.  jps：主要用来输出JVM中运行的进程状态信息，一般使用jps命令来查看进程的状态信息，包括JVM启动参数等。
2.  jinfo：主要用来观察进程运行环境参数等信息。
3.  jstack：主要用来查看某个Java进程内的线程堆栈信息。jstack pid 可以看到当前进程中各个线程的状态信息，包括其持有的锁和等待的锁。
4.  jmap：用来查看堆内存使用状况。jmap -heap pid可以看到当前进程的堆信息和使用的GC收集器，包括年轻代和老年代的大小分配等
5.  jstat：进行实时命令行的监控，包括堆信息以及实时GC信息等。可以使用jstat -gcutil pid1000来每隔一秒来查看当前的GC信息。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70]: /images/20230528/13d21c7c986d4877bdded3972381007a.png
[link]: https://blog.csdn.net/fengzhiqi1993/article/details/81191949
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzUxODAzOA_size_16_color_FFFFFF_t_70 1]: /images/20230528/87c70afb82284777aa68d9b99f58cecb.png