Java垃圾回收面试调优必知

淡淡的烟草味﹌ 2022-04-15 05:16 235阅读 0赞

本文大部分来源网络，本人进行总结整理，主要**是面试中垃圾回收相关频率较高的问题**以及解答.

# 常用的垃圾收集算法 #

### 标记-清除算法 ###

标记-清除算法采用从根集合（GC Roots）进行扫描，对存活的对象进行标记，标记完毕后，再扫描整个空间中未被标记的对象，进行回收，如下图所示。标记-清除算法不需要进行对象的移动，只需对不存活的对象进行处理，在存活对象比较多的情况下极为高效，但由于标记-清除算法直接回收不存活的对象，因此会造成内存碎片。

![1344248-20180318001610762-1345240312.jpg][]

### 复制算法 ###

复制算法的提出是为了克服句柄的开销和解决内存碎片的问题。它开始时把堆分成 一个对象 面和多个空闲面， 程序从对象面为对象分配空间，当对象满了，基于copying算法的垃圾 收集就从根集合（GC Roots）中扫描活动对象，并将每个 活动对象复制到空闲面(使得活动对象所占的内存之间没有空闲洞)，这样空闲面变成了对象面，原来的对象面变成了空闲面，程序会在新的对象面中分配内存。

![1344248-20180318001650696-538864007.jpg][]

### 标记-整理算法 ###

标记-整理算法采用标记-清除算法一样的方式进行对象的标记，但在清除时不同，在回收不存活的对象占用的空间后，会将所有的存活对象往左端空闲空间移动，并更新对应的指针。标记-整理算法是在标记-清除算法的基础上，又进行了对象的移动，因此成本更高，但是却解决了内存碎片的问题。具体流程见下图：

![1344248-20180318001700870-1306024111.jpg][]

### 分代收集算法 ###

分代收集算法是目前大部分JVM的垃圾收集器采用的算法。它的核心思想是根据对象存活的生命周期将内存划分为若干个不同的区域。一般情况下将堆区划分为老年代（Tenured Generation）和新生代（Young Generation），在堆区之外还有一个代就是永久代（Permanet Generation）。老年代的特点是每次垃圾收集时只有少量对象需要被回收，而新生代的特点是每次垃圾回收时都有大量的对象需要被回收，那么就可以根据不同代的特点采取最适合的收集算法。

![1344248-20180318001736534-846754340.jpg][]

**年轻代（Young Generation）的回收算法**

a) 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。

b) 新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后将survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。

c) 当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收。

d) 新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。

**老年代（Old Generation）的回收算法**

a) 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。

b) 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。

**持久代（Permanent Generation）的回收算法**

用于存放静态文件，如Java类、方法等。持久代对垃圾回收没有显著影响，但是有些应用可能动态生成或者调用一些class，例如Hibernate 等，在这种时候需要设置一个比较大的持久代空间来存放这些运行过程中新增的类。

# **垃圾收集器** #

**一、七种垃圾收集器**

**(1) Serial（串行GC）-XX:+UseSerialGC**

（复制算法)  
新生代单线程收集器，标记和清理都是单线程，优点是简单高效。是client级别默认的GC方式，可以通过`-XX:+UseSerialGC`来强制指定。

**(2) ParNew（并行GC）-XX:+UseParNewGC**

(停止-复制算法)　  
新生代收集器，可以认为是Serial收集器的多线程版本,在多核CPU环境下有着比Serial更好的表现。

**(3) Parallel Scavenge（并行回收GC）**

(停止-复制算法)  
并行收集器，追求高吞吐量，高效利用CPU。吞吐量一般为99%， 吞吐量= 用户线程时间/(用户线程时间+GC线程时间)。适合后台应用等对交互相应要求不高的场景。是server级别默认采用的GC方式，可用`-XX:+UseParallelGC`来强制指定，用`-XX:ParallelGCThreads=4`来指定线程数。

**(4) Serial Old（MSC）（串行GC）-XX:+UseSerialGC**

(标记-整理算法)  
老年代单线程收集器，Serial收集器的老年代版本。

**(5) CMS（并发GC）-XX:+UseConcMarkSweepGC**

（标记-清理算法）  
高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择。

**(6) Parallel Old（并行GC）-XX:+UseParallelOldGC**

(停止-复制算法)

收集器的老年代版本，并行收集器，吞吐量优先。

**(7) G1（JDK1.7update14才可以正式商用）**

![Image 1][]

**二.1~3用于年轻代垃圾回收**：年轻代的垃圾回收称为minor GC

**三.4~6用于年老代垃圾回收**（当然也可以用于方法区的回收）：年老代的垃圾回收称为full GC

G1独立完成"分代垃圾回收"

注意：并行与并发

并行：多条垃圾回收线程同时操作

并发：垃圾回收线程与用户线程一起操作

**四、常用五种组合**

Serial/Serial Old

ParNew/Serial Old：与上边相比，只是比年轻代多了多线程垃圾回收而已

ParNew/CMS：当下比较高效的组合

Parallel Scavenge/Parallel Old：自动管理的组合

G1：最先进的收集器，但是需要JDK1.7update14以上

**五. Serial/Serial Old**

年轻代Serial收集器采用单个GC线程实现"复制"算法（包括扫描、复制）

年老代Serial Old收集器采用单个GC线程实现"标记-整理"算法

Serial与Serial Old都会暂停所有用户线程（即STW）

说明：

STW（stop the world）：编译代码时为每一个方法注入safepoint（方法中循环结束的点、方法执行结束的点），在暂停应用时，需要等待所有的用户线程进入safepoint，之后暂停所有线程，然后进行垃圾回收。

适用场合：

CPU核数<2，物理内存<2G的机器（简单来讲，单CPU，新生代空间较小且对STW时间要求不高的情况下使用）

\-XX:UseSerialGC：强制使用该GC组合

\-XX:PrintGCApplicationStoppedTime：查看STW时间

**六.ParNew/Serial Old：**

ParNew除了采用多GC线程来实现复制算法以外，其他都与Serial一样，但是此组合中的Serial Old又是一个单GC线程，所以该组合是一个比较尴尬的组合，在单CPU情况下没有Serial/Serial Old速度快（因为ParNew多线程需要切换），在多CPU情况下又没有之后的三种组合快（因为Serial Old是单GC线程），所以使用其实不多。

\-XX:ParallelGCThreads：指定ParNew GC线程的数量，默认与CPU核数相同，该参数在于CMS GC组合时，也可能会用到

**七.Parallel Scavenge/Parallel Old：**

特点：

年轻代Parallel Scavenge收集器采用多个GC线程实现"复制"算法（包括扫描、复制）年老代Parallel Old收集器采用多个GC线程实现"标记-整理"算ParallelScavenge与Parallel Old都会暂停所有用户线程（即STW）

说明：

吞吐量：CPU运行代码时间/(CPU运行代码时间+GC时间)CMS主要注重STW的缩短（该时间越短，用户体验越好，所以主要用于处理很多的交互任务的情况）Parallel Scavenge/Parallel Old主要注重吞吐量（吞吐量越大，说明CPU利用率越高，所以主要用于处理很多的CPU计算任务而用户交互任务较少的情况）

参数设置：

\-XX:+UseParallelOldGC：使用该GC组合

\-XX:GCTimeRatio：直接设置吞吐量大小，假设设为19，则允许的最大GC时间占总时间的1/(1+19)，默认值为99，即1/(1+99)

\-XX:MaxGCPauseMillis：最大GC停顿时间，该参数并非越小越好

\-XX:+UseAdaptiveSizePolicy：开启该参数，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数就不起作用了，虚拟机会自动收集监控信息，动态调整这些参数以提供最合适的的停顿时间或者最大的吞吐量（GC自适应调节策略），而我们需要设置的就是-Xmx，-XX:+UseParallelOldGC或-XX:GCTimeRatio两个参数就好（当然-Xms也指定上与-Xmx相同就好）

注意：

\-XX:GCTimeRatio和-XX:MaxGCPauseMillis设置一个就好

不开启-XX:+UseAdaptiveSizePolicy，-Xmn/-XX:SurvivorRatio/-XX:PretenureSizeThreshold这些参数依旧可以配置，以resin服务器为例

\-Xms2048m -Xmx2048m -Xmn512m -Xss1m -XX:PermSize=256M -XX:MaxPermSize=256M -XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=15 -XX:+UseParallelOldGC -XX:GCTimeRatio=19 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps

适用场合：

很多的CPU计算任务而用户交互任务较少的情况不想自己去过多的关注GC参数，想让虚拟机自己进行调优工作

# GC是什么时候触发的（面试最常见的问题之一） #

由于对象进行了分代处理，因此垃圾回收区域、时间也不一样。GC有两种类型：Scavenge GC和Full GC。

###  Scavenge GC ###

一般情况下，当新对象生成，并且在Eden申请空间失败时（若大于最大空间则启动担保机制，关于担保机制可以了解一下），就会触发Scavenge GC，对Eden区域进行GC，清除非存活对象，并且把尚且存活的对象移动到Survivor区。然后整理Survivor的两个区。这种方式的GC是对年轻代的Eden区进行，不会影响到年老代。因为大部分对象都是从Eden区开始的，同时Eden区不会分配的很大，所以Eden区的GC会频繁进行。因而，一般在这里需要使用速度快、效率高的算法，使Eden去能尽快空闲出来。

### Full GC ###

对整个堆进行整理，包括Young、Tenured和Perm。Full GC因为需要对整个堆进行回收，所以比Scavenge GC要慢，因此应该尽可能减少Full GC的次数。在对JVM调优的过程中，很大一部分工作就是对于Full GC的调节。有如下原因可能导致Full GC：

a) 年老代（Tenured）被写满；

b) 持久代（Perm）被写满；

c) System.gc()被显示调用；

d) 上一次GC之后Heap的各域分配策略动态变化；

# JVM调优 #

（Jvm调优一般是指减少FullGC的执行频率或执行时间）

**新对象预留新生代**

由于fullGC(老年代)的成本远比minorGC（新生代和老年代）的成本大，所以给应用分配一个合理的新生代空间，尽量将对象分配到新生代减小fullGC的频率

**大对象进入老年代**

将大对象直接分配到老年代，保持新生代对象的结构的完整性，以提高GC效率， 以通过-XX:PretenureSizeThreshold设置进入老年代的阀值

**稳定与震荡的堆大小**

稳定的对大小是对垃圾回收有利的，方法将-Xms和-Xmx的大小一致

**吞吐量优先**

尽可能减少系统执行垃圾回收的总时间，故采用并行垃圾回收器

\-XX:+UseParallelGC或使用-XX:+UseParallelOldGC

** 降低停顿**

使用CMS回收器,同时减少fullGC的次数

[原文1][1]  
[原文2][2]

[1344248-20180318001610762-1345240312.jpg]: /images/20220415/2d370e45294c4750bc43aea63f1b2fc9.png
[1344248-20180318001650696-538864007.jpg]: /images/20220415/04f30c59bbd94169a9e6775187aa5a85.png
[1344248-20180318001700870-1306024111.jpg]: /images/20220415/2cff217102ef4c50a7711539959abdad.png
[1344248-20180318001736534-846754340.jpg]: /images/20220415/61bfeba01d974fc6a72a919ff6fae41f.png
[Image 1]: 
[1]: https://www.cnblogs.com/1024Community/p/honery.html
[2]: https://www.jianshu.com/p/22eea7306415