标签：收集器对象算法回收谈谈垃圾 JVM 内存

前言

垃圾回收需要思考三件事情，哪些内存需要回收？什么时候回收？如何回收？

一、哪些内存需要回收

JVM 的内存区域中，程序计数器、虚拟机栈和本地方法栈的生命周期是随线程而生，随线程而灭的。这几个区域的内存分配和回收都具有确定性，不需要过多考虑回收问题，当方法或线程结束时，内存自然就跟着回收了。

Java 堆和方法区是具有不确定性的，比如一个方法根据不同的条件执行可能需要的内存是不同的。只有处于运行期才能知道需要创建哪些对象，创建多少对象，这部分的内存分配和回收是动态的，垃圾回收所关注的就是这部分内存。

二、对象何时会“死亡”

Java 堆中存放了几乎所有的对象实例，垃圾回收器在进行回收前，需要判断哪些对象“存活”，哪些对象“死亡”，“死亡”的对象才会被回收。

1. 引用计数法

给对象中添加一个引用计数器：

每当有一个地方引用它，计数器就加 1；
当引用失效，计数器就减 1；
任何时候计数器为 0 的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。

2. 可达性分析算法

通过一系列被称为GC Roots的根对象作为起始节点集，从这些节点开始，通过引用关系向下搜寻，搜寻走过的路径称为“引用链”，如果某个对象到GC Roots没有任何“引用链”相连，就说明该对象不可达，即可以被回收。

如下图，Object 5、Object 6、Object 7 虽有关联，但是到GC Roots是不可达的，因此会被判定“死亡”。

Java 中固定可作为GC Root对象的有：

虚拟机栈的栈帧中的本地变量表中引用的对象，如，参数、局部变量、临时变量等。
方法区中类静态属性引用的对象，如，类中的静态变量。
方法区中常量引用的对象。
本地方法栈中 JNI（也就是native方法）引用的对象。
Java 虚拟机内部的引用，如基本数据类型对应的 Class 对象、常驻异常、系统类加载器等。
被同步锁持有的对象。

除了这些固定的还有一些临时性加入的，有兴趣的可以看下《深入理解 Java 虚拟机》。

上述两种方法都需要了解引用，详细介绍见Java引用。

3. 方法区的回收

不要求虚拟机在方法区进行垃圾回收，在 Java 堆中，尤其是在新生代中，常规进行一次垃圾收集通常可以回收70％至99％的内存空间，相比之下，在方法区进行回收的“性价比”较低。该区域的垃圾回收主要是两个部分，废弃的常量和不再使用的类。

3.1 废弃常量

假如在字符串常量池中曾存在字符串 "java"，如果当前没有任何字符串对象引用该字符串常量的话，就说明常量 "java" 就是废弃常量，如果这时发生内存回收的话而且有必要的话，"java" 就会被系统清理出常量池了。

3.2 不再被使用的类

类需要同时满足下面 3 个条件才能算是 “不在被使用的类” ：

该类所有的实例都已经被回收，也就是 Java 堆中不存在该类的任何实例。
加载该类的 ClassLoader 已经被回收。
该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

三、垃圾回收算法

这里整理的均为“追踪式垃圾回收“，也成为”间接垃圾回收“。

1. 分代回收

Java 堆的区域划分如下图，被分为新生代、老年代、永久代或元空间，具体划分为五大块区域，不同的 GC 会针对不同的区域进行垃圾回收。

GC类型一般有以下几大类：

分类	说明
Minor GC	也称“Young GC”，只针对新生代进行的垃圾回收。
Major GC	也称“Old GC”，只针对老年代进行的垃圾回收
Mixed GC	针对新生代和部分老年代进行垃圾回收，部分垃圾收集器才支持。
Full GC	针对整个Java堆和方法区进行的垃圾回收，耗时最久的GC

2. 标记-清除算法

最早出现的垃圾回收算法，分为“标记”、“清除”两个阶段。可以标记存活的对象，也可以标记要回收的对象。
该算法有两个缺点：

是执行效率不稳定，随着对象的增多，标记效率会越来越低；
内存空间产生很多碎拼，浪费空间，分配大对象时可能需要重新触发垃圾回收。

标记-清除算法执行过程如下图：

3. 标记-复制算法

简称复制算法，为了解决标记-清除算法面对大量可回收对象执行效率低的问题，就是将内存分成两个区域，每次只使用其中一个区域，当该区域内存满了之后，会将还存活的对象复制到另一个区域，然后将原区域直接清理掉。
该算法有两个缺点：

对象存活率过多时，会影响复制的效率；
一半内存不使用，浪费了大量空间。

标记-复制算法执行过程如下图：

由于 Java 的新生代对象存活率不高，所以一般针对新生代的垃圾回收使用标记-复制算法。

如下图，将新生代分为内存较大的Eden，和两块内存较小的Survivor。每次分配内存只使用Eden和其中一个Survivor，我们假设第一次分配内存是Eden、Survivor 0。

发生 GC 时，将使用的Eden、Survivor 0中存活的对象一次性复制到Survivor 1中，然后清理掉Eden、Survivor 0内存。
这时分配的内存就变成了Eden、Survivor 1，周而复始。

注意：当Survivor不足以容纳轻 GC 之后的对象时，就需要依赖老年代来进行内存分配了。

4. 标记-整理算法

标记完存活对象以后，让所有存活对象都向内存空间的一端移动，然后在清理掉边界以外的内存。

标记-整理算法执行过程如下图：

这种涉及到了对象的移动，如果移动存活对象，尤其是老年代这种每次回收都有大量对象存活的区域，会耗时很多，并且对象移动操作会全部暂停用户应用程序才能进行，这样会产生停顿时间。

这种停顿被称为Stop The World。

5. 标记-清除-整理算法

先使用标记-清除算法进行垃圾回收，暂时容忍内存碎片的存在，直到碎片过多影响对象分配时，在进行标记-整理算法进行回收，获得规整空间。

四、经典垃圾收集器

下图展示了 7 种经典垃圾收集器，若两两出现互连情况，则表明两者它们可以搭配使用。

单线程收集器 Serial、Serial old
并行收集器 Par New、Parallel Scavenge、Parallel old
并发收集器 CMS、G1

1. Serial 收集器

最基本、历史最早的垃圾收集器了。单线程的收集器，收集垃圾时，必须暂停其他所有工作线程，也就是必有停顿，使用复制算法。

2. Par New 收集器

多线程并行版本的 Serial 收集器，收集垃圾时，必须暂停其他所有工作线程，也就是必有停顿，使用复制算法。

3. Parallel Scavenge 收集器

类似 Par New 收集器，但关注点是达到一个可控的吞叶量，使用复制算法。

吞吐量公式：

吞吐量示例：

代码运行 95 秒 , 垃圾收集器运行 5 秒 , 那么吞吐量就是 $\frac{95}{95 + 5} = 0.95$

4. Serial old 收集器

Serial 收集器的老年代版本，单线程收集器，使用标记-整理算法。它主要有两大用途：

在JDK1.5及以前的版本中与 Parallel Scavenge 收集器搭配使用;
作为CMS收集器的后备方案。

5. Parallel old 收集器

Parallel Scavenge收集器的老年代版本。使用多线程和标记-整理算法。在注重吞吐量以及CPU资源的场合，都可以优先考虑 Parallel Scavenge收集器和Parallel Old收集器（JDK8默认的新生代和老年代收集器）。

6. CMS 收集器

是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

整个过程分为5个步骤：初始标记→并发标记→重新标记→并发清理→并发重置。

7. G1 收集器

基于标记整理算法实现，运作流程主要包括以下：初始标→并发标记→最终标记→筛选回收，不会产生空间碎片，可以精确地控制停顿，可以支持用户设置期望停顿时间。

不追求一次性将 Java 堆清理干净，只要垃圾收集的速度赶得上对象分配的速度即可。

参考：

[1] 周志明. 深入理解 Java 虚拟机（第3版）.

标签：收集器,对象,算法,回收,谈谈,垃圾,JVM,内存
From： https://www.cnblogs.com/fuxing/p/18193599

谈谈 JVM 垃圾回收机制

前言