jvm的内存划分和垃圾回收

偏执的太偏执、 2022-05-19 05:47 145阅读 0赞

一、jvm的内存划分

我们将jvm的内存划分为线程单独区和线程共享区，线程单独区就是每个线程单独有的，线程共享区就是线程都共享的区域。jvm中有5块内存区域。

线程单独区：程序计数器、Java 虚拟机栈、本地方法栈

线程共享区：Java 堆、方法区（运行时常量池）

![70][]

1）程序计数器

程序计数器（Program Counter Register）是一块**较小的内存空间**，它的作用可以看做是当前线程所执行的字节码的行号指示器。在虚拟机的概念模型里（仅是概念模型，各种虚拟机可能会通过一些更高效的方式去实现），字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等基础功能都需要依赖这个计数器来完成。由于Java 虚拟机的多线程是通过**线程轮流切换**并分配处理器执行时间的方式来实现的，**在任何一个确定的时刻，一个处理器（对于多核处理器来说是一个内核）只会执行一条线程中的指令**。因此，**为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器**，**各条线程之间的计数器互不影响，独立存储**，我们称这类内存区域为“线程私有”的内存。如果线程正在执行的是一个Java 方法，**这个计数器记录的是正在执行的虚拟机字节码指令的地址**；**如果正在执行的是Natvie 方法，这个计数器值则为空（Undefined）**。**此内存区域是唯一一个在Java 虚拟机规范中没有规定任何OutOfMemoryError 情况的区域**。

2）Java 虚拟机栈

与程序计数器一样，Java 虚拟机栈（Java Virtual Machine Stacks）也是线程私有的，**它的生命周期与线程相同**。虚拟机栈描述的是Java 方法执行的内存模型：每个方法被执行的时候都会同时创建一个**栈帧**（Stack Frame ①）用于存储局部变量表、操作栈、动态链接、方法出口等信息。**每一个方法被调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中从入栈到出栈的过程**。经常有人把Java 内存区分为堆内存（Heap）和栈内存（Stack），这种分法比较粗糙，Java 内存区域的划分实际上远比这复杂。这种划分方式的流行只能说明大多数程序员最关注的、与对象内存分配关系最密切的内存区域是这两块。其中所指的“堆”在后面会专门讲述，而所指的“栈”就是现在讲的虚拟机栈，或者说是虚拟机栈中的局部变量表部分。

**局部变量表存放了编译期可知的各种基本数据类型**（boolean、byte、char、short、int、float、long、double）、**对象引用**（reference 类型，它不等同于对象本身，根据不同的虚拟机实现，它可能是一个指向对象起始地址的引用指针，也可能指向一个代表对象的句柄或者其他与此对象相关的位置）和returnAddress 类型（指向了一条字节码指令的地址）。其中64 位长度的long 和double 类型的数据会占用**2 个局部变量空间**（Slot），其余的数据类型**只占用1 个**。**局部变量表所需的内存空间在编译期间完成分配**，当进入一个方法时，这个方法需要在帧中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。

在Java 虚拟机规范中，对这个区域规定了两种异常状况：**如果线程请求的栈深度大于虚拟机所允许的深度**，将抛出**StackOverflowError** 异常；如果虚拟机栈可以动态扩展（当前大部分的Java 虚拟机都可动态扩展，只不过Java 虚拟机规范中也允许固定长度的虚拟机栈），当扩展时无法申请到足够的内存时会抛出**OutOfMemoryError** 异常。

3）本地方法栈

本地方法栈（Native Method Stacks）与虚拟机栈所发挥的作用是非常相似的，其区别不过是**虚拟机栈为虚拟机执行Java 方法（也就是字节码）服务**，**而本地方法栈则是为虚拟机使用到的Native 方法服务**。虚拟机规范中对本地方法栈中的方法使用的语言、使用方式与数据结构并没有强制规定，因此具体的虚拟机可以自由实现它。甚至有的虚拟机（譬如Sun HotSpot 虚拟机）直接就把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样，本地方法栈区域也会抛出**StackOverflowError **和**OutOfMemoryError**异常。

4）Java 堆

对于大多数应用来说，Java 堆（Java Heap）是Java 虚拟机所管理的**内存中最大**的一块。Java 堆是被所有线程**共享**的一块内存区域，**在虚拟机启动时创建**。此内存区域的唯一目的就是**存放对象实例**，几乎所有的对象实例都在这里分配内存。这一点在Java 虚拟机规范中的描述是：**所有的对象实例以及数组都要在堆上分配**，但是随着**JIT 编译器**的发展与**逃逸分析技术**的逐渐成熟，**栈上分配、标量替换优化技术**将会导致一些微妙的变化发生，所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。**Java 堆是垃圾收集器管理的主要区域**，因此很多时候也被称做“GC 堆”（GarbageCollected Heap，幸好国内没翻译成“垃圾堆”）。如果从内存回收的角度看，由于现在收集器基本都是采用的**分代收集算法**，所以Java 堆中还可以细分为：**新生代**和**老年代**；再细致一点的有**Eden 空间**、**From Survivor 空间**、**To Survivor 空间**等。如果从内存分配的角度看，**线程共享的Java 堆中可能划分出多个线程私有的分配缓冲区（Thread LocalAllocation Buffer，TLAB）**。不过，无论如何划分，都与存放内容无关，无论哪个区域，存储的都仍然是对象实例，进一步划分的目的是为了更好地回收内存，或者更快地分配内存。

根据Java 虚拟机规范的规定，**Java 堆可以处于物理上不连续的内存空间中**，**只要逻辑上是连续的即可**，就像我们的磁盘空间一样。在实现时，既可以实现成固定大小的，也可以是可扩展的，不过当前主流的虚拟机都是按照可扩展来实现的（通过-Xmx和-Xms 控制）。如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出**OutOfMemoryError** 异常。

其中堆内存在不同的jvm中有划分为不同的，其中垃圾回收的也主要是管理堆职工的空间。

<table> 
 <tbody> 
  <tr> 
   <td> <p>1.&nbsp;<strong>年轻代</strong>（<strong>Young Generation</strong>）</p> <p>Java应用在分配Java对象时，这些对象会被分配到年轻代堆空间中去</p> <p>这个空间大多是小对象并且会被频繁回收</p> <p>由于年轻代堆空间的垃圾回收会很频繁，因此其垃圾回收算法会更加重视回收效率</p> <p>2.&nbsp;<strong>年老代</strong>（<strong>Old Generationn</strong>）</p> <p>年轻代堆空间的长期存活对象会转移到（也许是永久性转移）年老代堆空间</p> <p>这个堆空间通常比年轻代的堆空间大，并且其空间增长速度较缓</p> <p>由于大部分JVM堆空间都分配给了年老代，因此其垃圾回收算法需要更节省空间，此算法需要能够处理低垃圾密度的堆空间</p> <p>3.&nbsp;<strong>持久代</strong>（<strong>Permanent Generation</strong>）</p> <p>存放VM和Java类的元数据（metadata），以及interned字符串和类的静态变量</p> </td> 
  </tr> 
 </tbody> 
</table>

5）方法区

方法区（Method Area）与Java 堆一样，是各个线程共享的内存区域，**它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据**。虽然Java 虚拟机规范把方法区描述为堆的一个逻辑部分，但是它却有一个别名叫做Non-Heap（非堆），目的应该是与Java 堆区分开来。

对于习惯在HotSpot 虚拟机上开发和部署程序的开发者来说，很多人愿意把方法区称为“**永久代**”（Permanent Generation），**本质上两者并不等价**，仅仅是因为HotSpot 虚拟机的设计团队选择把GC 分代收集扩展至方法区，或者说使用永久代来实现方法区而已。对于其他虚拟机（如BEA JRockit、IBM J9 等）来说是不存在永久代的概念的。即使是HotSpot 虚拟机本身，根据官方发布的路线图信息，现在也有放弃永久代并“搬家”至Native Memory 来实现方法区的规划了。

Java 虚拟机规范对这个区域的限制非常宽松，除了和Java 堆一样不需要连续的内存和可以选择固定大小或者可扩展外，还可以选择不实现垃圾收集。相对而言，**垃圾收集行为在这个区域是比较少出现的**，但并非数据进入了方法区就如永久代的名字一样“永久”存在了。**这个区域的内存回收目标主要是针对常量池的回收和对类型的卸载**，一般来说这个区域的回收“成绩”比较难以令人满意，尤其是类型的卸载，条件相当苛刻，但是这部分区域的回收确实是有必要的。在Sun 公司的BUG 列表中，曾出现过的若干个严重的BUG 就是由于低版本的HotSpot 虚拟机对此区域未完全回收而导致内存泄漏。根据Java 虚拟机规范的规定，当方法区无法满足内存分配需求时，将抛出**OutOfMemoryError **异常。

![70 1][]

其中方法区中包含的是class文件信息和运行时常量：

class文件信息：class文件的信息包括类信息和静态常量池，

静态常量池：就是class文件信息中的class文件常量池，静态常量池存储的是当class文件被**java虚拟机加载进来**后存放在方法区的一些字面量和符号引用，字面量包括字符串，基本类型的常量，符号引用其实引用的就是常量池里面的字符串，但符号引用不是直接存储字符串，而是存储字符串在常量池里的索引。

动态常量池：是当class文件被加载完成后，java虚拟机会将静态常量池里的内容转移到动态常量池里，在静态常量池的符号引用有一部分是会被转变为直接引用的，比如说类的静态方法或私有方法，实例构造方法，父类方法，这是因为这些方法不能被重写其他版本，所以能在加载的时候就可以将符号引用转变为直接引用，而其他的一些方法是在这个方法被第一次调用的时候才会将符号引用转变为直接引用的。

![70 2][]

6）运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。Class 文件中除了有类的版本、字段、方法、接口等描述等信息外，还有一项信息是**常量池**（Constant Pool Table），用于存放编译期生成的各种字面量和符号引用，这部分内容将在类加载后存放到方法区的运行时常量池中。

Java 虚拟机对Class 文件的每一部分（自然也包括常量池）的格式都有严格的规定，每一个字节用于存储哪种数据都必须符合规范上的要求，这样才会被虚拟机认可、装载和执行。但对于运行时常量池，Java 虚拟机规范没有做任何细节的要求，不同的提供商实现的虚拟机可以按照自己的需要来实现这个内存区域。不过，一般来说，除了保存Class 文件中描述的符号引用外，还会把翻译出来的直接引用也存储在运行时常量池中。

运行时常量池相对于Class 文件常量池的另外一个重要特征是具备动态性，Java 语言并不要求常量一定只能在编译期产生，也就是并非预置入Class 文件中常量池的内容才能进入方法区运行时常量池，运行期间也可能将新的常量放入池中，这种特性被开发人员利用得比较多的便是String 类的intern() 方法。既然运行时常量池是方法区的一部分，自然会受到方法区内存的限制，当常量池无法再申请到内存时会抛出OutOfMemoryError 异常。

7）直接内存

直接内存（Direct Memory）并不是虚拟机运行时数据区的一部分，也不是Java虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用，而且也可能导致OutOfMemoryError 异常出现，所以我们放到这里一起讲解。在JDK 1.4 中新加入了NIO（New Input/Output）类，引入了一种基于通道（Channel）与缓冲区（Buffer）的I/O 方式，它可以使用Native 函数库直接分配堆外内存，然后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java 堆和Native 堆中来回复制数据。

显然，本机直接内存的分配不会受到Java 堆大小的限制，但是，既然是内存，则肯定还是会受到本机总内存（包括RAM 及SWAP 区或者分页文件）的大小及处理器寻址空间的限制。服务器管理员配置虚拟机参数时，一般会根据实际内存设置-Xmx等参数信息，但经常会忽略掉直接内存，使得各个内存区域的总和大于物理内存限制（包括物理上的和操作系统级的限制），从而导致动态扩展时出现OutOfMemoryError异常。

二、内存的分配（对象在堆中分配的原则）

1）对象优先在新生代（Young Generation）中的eden区域进行分配

注意：堆内存一般划分为新生代和老年代（1:2比例，老年代内存大），而新生代有划分为Eden和两个survivor代（8:1:1）的比例进行划分。

2）大对象直接进入老年代

3）长期存活的对象进入老年代

4）动态对象年龄判定

5）空间分配担保

三、垃圾回收的原理

垃圾回收的原理：确定垃圾回收的区域——>判断哪些垃圾可以回收——>垃圾回收的策略和算法

1）垃圾回收的内存区域（哪些区域需要回收）

JVM的内存结构包括五大区域：程序计数器、虚拟机栈、本地方法栈、堆区、方法区。其中程序计数器、虚拟机栈、本地方法栈3个区域随线程而生、随线程而灭，因此这几个区域的内存分配和回收都具备确定性，就不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。而Java堆区和方法区则不一样，这部分内存的分配和回收是动态的，正是垃圾收集器所需关注的部分。也就是线程单独的内存是更随线程变化的，不用过多的考虑，而内存饿共享区域是垃圾回收的主要考虑区域。垃圾收集器在对堆区和方法区进行回收前，首先要确定这些区域的对象哪些可以被回收，哪些暂时还不能回收，这就要用到判断对象是否存活的算法！

**堆中主要回收的是对象**

**方法区职工主要回收的是废弃常量和无用的类**

2）确定内存区域是否为垃圾的算法（就是怎么判断一个对象是否可以回收，也就是怎么判断是个垃圾）

***堆内存中的回收算法：引用计数算法***、***可达性分析算（主要）***

***引用计数算法***

**算法分析：**引用计数是垃圾收集器中的早期策略。在这种方法中，堆中每个对象实例都有一个引用计数。当一个对象被创建时，就将该对象实例分配给一个变量，该变量计数设置为1。当任何其它变量被赋值为这个对象的引用时，计数加1（a = b,则b引用的对象实例的计数器+1），但当一个对象实例的某个引用超过了生命周期或者被设置为一个新值时，对象实例的引用计数器减1。任何引用计数器为0的对象实例可以被当作垃圾收集。当一个对象实例被垃圾收集时，它引用的任何对象实例的引用计数器减1。

**优点**：引用计数收集器可以很快的执行，交织在程序运行中。对程序需要不被长时间打断的实时环境比较有利。

**缺点**：无法检测出循环引用。如父对象有一个对子对象的引用，子对象反过来引用父对象。这样，他们的引用计数永远不可能为0。

**实例分析**：

public class ReferenceFindTest {
        public static void main(String[] args) {
            MyObject object1 = new MyObject();
            MyObject object2 = new MyObject();
              
            object1.object = object2;
            object2.object = object1;
    
            object1 = null;
            object2 = null;
        }
    }

这段代码是用来验证引用计数算法不能检测出循环引用。最后面两句将`object1`和`object2`赋值为`null`，也就是说`object1`和`object2`指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数器都不为0，那么垃圾收集器就永远不会回收它们。

***可达性分析算法（主要）***

**算法分析：**可达性分析算法是从离散数学中的图论引入的，程序把所有的引用关系看作一张图，从一个节点GC ROOT开始，寻找对应的引用节点，找到这个节点以后，继续寻找这个节点的引用节点，当所有的引用节点寻找完毕之后，剩余的节点则被认为是没有被引用到的节点，即无用的节点，无用的节点将会被判定为是可回收的对象。

![1344248-20180318001527338-249406891.jpg][]

在Java语言中，可作为GC Roots的对象包括下面几种：

a) 虚拟机栈中引用的对象（栈帧中的本地变量表）；

b) 方法区中类静态属性引用的对象；

c) 方法区中常量引用的对象；

d) 本地方法栈中JNI（Native方法）引用的对象。

**可达性分析算法回收对象过程**：

即使在可达性分析算法中不可达的对象，也并非是“非死不可”，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历两次标记过程。**第一次标记**：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记；**第二次标记**：第一次标记后接着会进行一次筛选，筛选的条件是此对象是否有必要执行`finalize()`方法。在`finalize()`方法中没有重新与引用链建立关联关系的，将被进行第二次标记。第二次标记成功的对象将真的会被回收，如果对象在`finalize()`方法中重新与引用链建立了关联关系，那么将会逃离本次回收，继续存活。

<table> 
 <tbody> 
  <tr> 
   <td> <p style="margin-left:10px;"><span style="color:#333333;">补充内容：</span></p> <p style="margin-left:10px;"><span style="color:#333333;">无论是通过<strong>引用计数算</strong>法判断对象的引用数量，还是通过<strong>可达性分析算</strong>法判断对象的引用链是否可达，判定对象是否存活都与“引用”有关。在Java语言中，将引用又分为<strong>强引用</strong>、<strong>软引用</strong>、<strong>弱引用</strong>、<strong>虚引用</strong>4种，这四种引用强度依次逐渐减弱。</span></p> 
    <ul> 
     <li><span style="color:#0099ff;">强引用</span>：<span style="color:#333333;">在程序代码中普遍存在的，类似&nbsp;<code>Object obj = new Object()</code>&nbsp;这类引用，只要强引用还存在，垃圾收集器永远不会回收掉被引用的对象。</span></li> 
     <li><span style="color:#0099ff;">软引用</span>：<span style="color:#333333;">用来描述一些还有用但并非必须的对象。对于软引用关联着的对象，在系统将要发生内存溢出异常之前，将会把这些对象列进回收范围之中进行第二次回收。如果这次回收后还没有足够的内存，才会抛出内存溢出异常。</span></li> 
     <li><span style="color:#0099ff;">弱引用</span>：<span style="color:#333333;">也是用来描述非必需对象的，但是它的强度比软引用更弱一些，被弱引用关联的对象<strong>只能生存到下一次垃圾收集发生之前</strong>。当垃圾收集器工作时，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。</span></li> 
     <li><span style="color:#0099ff;">虚引用</span>：<span style="color:#333333;">也叫幽灵引用或幻影引用，是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。它的作用是能在这个对象被收集器回收时收到一个系统通知。</span></li> 
    </ul><p><span style="color:#333333;">无论引用计数算法还是可达性分析算法都是<strong>基于强引用</strong>而言的。</span></p> </td> 
  </tr> 
 </tbody> 
</table>

***方法区内存中的回收算法：***

方法区存储内容是否需要回收的判断可就不一样。方法区主要回收的内容有：**废弃常量**和**无用的类**。

废弃常量也可通过引用的可达性来判断

无用的类则需要同时满足下面3个条件：1、该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例；2、加载该类的`ClassLoader`已经被回收；3、该类对应的`java.lang.Class`对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

2）垃圾回收的机制（判断对象或者类是垃圾之后，就要采用那种策略去回收这些垃圾）

垃圾回收的算法：**标记-清除算法、复制算法、标记-整理算法、分代收集算法（主流算法）**

**标记-清除算法**：标记-清除算法采用从根集合（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）的回收算法

<table> 
 <tbody> 
  <tr> 
   <td> <p>a) 所有新生成的对象首先都是放在年轻代的。年轻代的目标就是尽可能快速的收集掉那些生命周期短的对象。</p> <p>b) 新生代内存按照8:1:1的比例分为一个eden区和两个survivor(survivor0,survivor1)区。一个Eden区，两个 Survivor区(一般而言)。大部分对象在Eden区中生成。回收时先将eden区存活对象复制到一个survivor0区，然后清空eden区，当这个survivor0区也存放满了时，则将eden区和survivor0区存活对象复制到另一个survivor1区，然后清空eden和这个survivor0区，此时survivor0区是空的，然后survivor0区和survivor1区交换，即保持survivor1区为空， 如此往复。</p> <p>c) 当survivor1区不足以存放 eden和survivor0的存活对象时，就将存活对象直接存放到老年代。若是老年代也满了就会触发一次Full GC，也就是新生代、老年代都进行回收。</p> <p>d) 新生代发生的GC也叫做Minor GC，MinorGC发生频率比较高(不一定等Eden区满了才触发)。</p> </td> 
  </tr> 
 </tbody> 
</table>

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

<table> 
 <tbody> 
  <tr> 
   <td> <p>a) 在年轻代中经历了N次垃圾回收后仍然存活的对象，就会被放到年老代中。因此，可以认为年老代中存放的都是一些生命周期较长的对象。</p> <p>b) 内存比新生代也大很多(大概比例是1:2)，当老年代内存满时触发Major GC即Full GC，Full GC发生频率比较低，老年代对象存活时间比较长，存活率标记高。</p> </td> 
  </tr> 
 </tbody> 
</table>

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

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

--------------------

垃圾收集器：**Serial收集器（复制算法)、Serial Old收集器(标记-整理算法)、ParNew收集器(停止-复制算法)、Parallel Scavenge收集器(停止-复制算法)、Parallel Old收集器(停止-复制算法)、CMS(Concurrent Mark Sweep)收集器（标记-清理算法）**

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

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

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

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

**Parallel Old收集器(停止-复制算法)**：Parallel Scavenge收集器的老年代版本，并行收集器，吞吐量优先。

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

![70 3][]

垃圾收集器的触发时间：

由于对象进行了**分代处理**，因此垃圾回收区域、时间也不一样。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的各域分配策略动态变化；

[70]: /images/20220519/aced1a68a2d044609c3786a28cd323d8.png
[70 1]: /images/20220519/1210fe01db214fc5b5f228aede8d41ee.png
[70 2]: /images/20220519/42fe9bda75744013a619bc3d1ba8347b.png
[1344248-20180318001527338-249406891.jpg]: /images/20220519/541f1624891e47e19f19bcb2d9513105.png
[1344248-20180318001610762-1345240312.jpg]: /images/20220519/9bdce31a2e08431a97f33419c19d3bb8.png
[1344248-20180318001650696-538864007.jpg]: /images/20220519/bf5e940222e146e5b4769785623586c2.png
[1344248-20180318001700870-1306024111.jpg]: /images/20220519/2e11420146a54baa97e7a57caf598876.png
[1344248-20180318001736534-846754340.jpg]: /images/20220519/bd1a4d4489594c009baba46aefe487b2.png
[70 3]: /images/20220519/d71729d0f7f64a4c99ae244c232c7d87.png