JVM内存模型以及垃圾回收(详细总结)

川长思鸟来 2022-09-05 05:23 172阅读 0赞

### JVM内存模型以及垃圾回收 ###

*  JVM内存模型
 *  浅谈JAVA中的对象和对象引用
 *  JAVA垃圾回收机制
 *  判断哪些对象需要被回收
 *  垃圾收集算法
 *   *  标记-清除算法
     *  复制算法
     *  标记整理算法
     *  分代收集算法
 *  垃圾收集器
 *   *  Serial收集器（串行收集器）
     *  ParNew收集器
     *  Parallel Scavenge收集器
     *  CMS收集器
     *  G1收集器

# JVM内存模型 #

一个完整的JAVA执行流程如下所示:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70]  
以.java文件结尾的称作源代码文件,它经过编译器编译之后形成了.class文件(字节码文件),然后由JVM中的类加载器进行加载各个类的字节码文件,加载完毕之后,由JVM执行引擎执行.在整个执行的过程中,JVM会用一段空间来存储期间所用到的数据和相关信息,这段空间一般被称作为Runtime Data Area（运行时数据区），也就是我们常说的JVM内存。  
这一部门的结构如下所示:  
![在这里插入图片描述][5d52ce9a6e094f80b9981d5c5b57b866.png]  
**方法区**:是线程所共享的区域,主要是用于存储类相关的信息,常量和静态变量。当方法区无法满足内存分配需求时，将抛出OutOfMemoryError 异常。

**堆**:Java 堆也是属于线程共享的内存区域，它在虚拟机启动时创建，是Java 虚拟机所管理的内存中最大的一块，主要用于存放对象实例，几乎所有的对象实例都在这里分配内存，注意Java 堆是垃圾收集器管理的主要区域，因此很多时候也被称做GC 堆，如果在堆中没有内存完成实例分配，并且堆也无法再扩展时，将会抛出OutOfMemoryError 异常。

**程序计数器**：记录字节码所执行的位置。多线程中，为了让线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，各条线程之间互不影响、独立存储，因此这块内存是线程私有的。

**虚拟机栈**：Java虚拟机栈也是线程私有的，它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型：每个方法在执行的同时都会创建一个栈帧用于存储局部变量表、操作数栈、动态链表、方法出口信息等。每一个方法从调用直至执行完成的过程，就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。

**本地方法栈**:与虚拟机栈类似，只是虚拟机服务的对象不同而已，虚拟机栈服务的是Java方法，而本地方法栈服务的是本地方法即native方法

# 浅谈JAVA中的对象和对象引用 #

为了方便理解下文的中的内容,我们首先了解下JAVA中对象和对象引用。在Java中，有一组名词经常一起出现，它们就是“对象和对象引用”。今天我们就来一起了解一下对象和对象引用之间的区别和联系。

《Java编程思想》这本书中有这么一个说法:“每种编程语言都有自己的数据处理方式。有些时候，程序员必须注意将要处理的数据是什么类型。你是直接操纵元素，还是用某种基于特殊语法的间接表示（例如C/C++里的指针）来操作对象。所有这些在 Java 里都得到了简化，一切都被视为对象。因此，我们可采用一种统一的语法。尽管将一切都“看作”对象，但操纵的标识符实际是指向一个对象的“引用”（reference）。”

举个例子，我们通常会用下面这一行代码来创建一个对象：

Person person = new Person("张三");

有人会说，这里的person是一个对象，是Person类的一个实例。  
也有人会说，这里的person并不是真正的对象，而是指向所创建的对象的引用。  
到底哪种说法是对的？我们先不急着纠结哪种说法是对的，再看两行代码：

Person person;
    person = new Person("张三");

这两行代码实现的功能和上面的一行代码是完全一样的。大家都知道，在Java中new是用来在堆上创建对象用的，如果person是一个对象的话，那么第二行为何还要通过new来创建对象呢？由此可见，person并不是所创建的对象，是什么？上面的一段话说的很清楚，“操纵的标识符实际是指向一个对象的引用”，也就是说person是一个引用，是指向一个可以指向Person类的对象的引用。真正创建对象的语句是右边的new Person(“张三”);  
再看一个例子：

Person person;
    person = new Person("张三");
    person = new Person("李四");

这里让person先指向了“张三”这个对象，然后又指向了“李四”这个对象。也就是说，Person person，这句话只是声明了一个Person类的引用，它可以指向任何Person类的实例。  
也就是说，一个引用可以指向多个对象，而一个对象可不可以被多个引用所指呢？答案当然是可以的。  
比如:

Person person1 = new Person("张三");
    Person person2 = person1;

# JAVA垃圾回收机制 #

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 1]  
上图是JVM的内存模型以及具体的划分.  
Java 内存运行时区域中的程序计数器、虚拟机栈、本地方法栈随线程而生灭；栈中的栈帧随着方法的进入和退出而有条不紊地执行着出栈和入栈操作。每一个栈帧中分配多少内存基本上是在类结构确定下来时就已知的（尽管在运行期会由 JIT 编译器进行一些优化），因此这几个区域的内存分配和回收都具备确定性，不需要过多考虑回收的问题，因为方法结束或者线程结束时，内存自然就跟随着回收了。

而 Java 堆不一样，一个接口中的多个实现类需要的内存可能不一样，一个方法中的多个分支需要的内存也可能不一样，我们只有在程序处于运行期间时才能知道会创建哪些对象，这部分内存的分配和回收都是动态的，垃圾收集器所关注的是这部分内存。

# 判断哪些对象需要被回收 #

有以下两种方法：  
(1)引用计数法  
给对象添加一引用计数器，被引用一次计数器值就加 1；当引用失效时，计数器值就减 1；计数器为 0 时，对象就是不可能再被使用的，简单高效，**缺点是无法解决对象之间相互循环引用的问题**。  
(2)可达性分析算法  
通过一系列的称为 “GC Roots” 的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。**此算法解决了上述循环引用的问题**。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 2]  
在Java语言中，可作为 GC Roots 的对象包括下面几种：  
a. 虚拟机栈（栈帧中的本地变量表）中引用的对象。  
b. 方法区中类静态属性引用的对象。  
c. 方法区中常量引用的对象。  
d. 本地方法栈中 JNI（Native方法）引用的对象  
**GC的主要区域是堆和方法区**

# 垃圾收集算法 #

## 标记-清除算法 ##

最基础的收集算法是“标记-清除”（Mark-Sweep）算法，分为“标记”和“清除”两个阶段：首先标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。  
它的主要不足有两个：  
1.效率问题，标记和清除两个过程的效率都不高；  
2.空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 3]

## 复制算法 ##

为了解决效率问题，一种称为“复制”（Copying）的收集算法出现了，它将可用内存按容量划分为大小相等的两块，每次只使用其中的一块。当这一块的内存用完了，就将还存活着的对象复制到另外一块上面，然后再把已使用过的内存空间一次清理掉。

这样使得每次都是对整个半区进行内存回收，内存分配时也就不用考虑内存碎片等复杂情况，只要移动堆顶指针，按顺序分配内存即可，实现简单，运行高效。只是这种算法的代价是将内存缩小为了原来的一半。复制算法的执行过程如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 4]

现在的商业虚拟机都采用这种算法来回收新生代，IBM 研究指出新生代中的对象 98% 是“朝生夕死”的，所以并不需要按照 1:1 的比例来划分内存空间，而是将内存分为一块较大的 Eden 空间和两块较小的 Survivor 空间，每次使用 Eden 和其中一块 Survivor 。

## 标记整理算法 ##

复制算法在对象存活率较高时就要进行较多的复制操作，效率将会变低。更关键的是，如果不想浪费 50% 的空间，就需要有额外的空间进行分配担保，以应对被使用的内存中所有对象都 100% 存活的极端情况，所以在老年代一般不能直接选用这种算法。

根据老年代的特点，有人提出了另外一种“标记-整理”（Mark-Compact）算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存，“标记-整理”算法的示意图如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 5]

## 分代收集算法 ##

当前商业虚拟机的垃圾收集都采用“分代收集”（Generational Collection）算法，根据对象存活周期的不同将内存划分为几块并采用不用的垃圾收集算法。  
**新生代**（Young generation）：绝大多数最新被创建的对象都会被分配到这里，由于大部分在创建后很快变得不可达，很多对象被创建在新生代，然后“消失”。对象从这个区域“消失”的过程我们称之为：Minor GC 。

**老年代**（Old generation）：对象没有变得不可达，并且从新生代周期中存活了下来，会被拷贝到这里。其区域分配的空间要比新生代多。也正由于其相对大的空间，发生在老年代的GC次数要比新生代少得多。对象从老年代中消失的过程，称之为：Major GC 或者 Full GC。

**持久代**（Permanent generation）也称之为 方法区（Method area）：用于保存类常量以及字符串常量。注意，这个区域不是用于存储那些从老年代存活下来的对象，这个区域也可能发生GC。发生在这个区域的GC事件也被算为 Major GC 。

新生代空间的构成与逻辑

为了更好的理解GC，我们来学习新生代的构成，它用来保存那些第一次被创建的对象，它被分成三个空间：

· 一个伊甸园空间（Eden）

· 两个幸存者空间（Fron Survivor、To Survivor）

默认新生代空间的分配：Eden : Fron : To = 8 : 1 : 1  
每个空间的执行顺序如下：

1、绝大多数刚刚被创建的对象会存放在伊甸园空间（Eden）。

2、在伊甸园空间执行第一次GC（Minor GC）之后，存活的对象被移动到其中一个幸存者空间（Survivor）。

3、此后，每次伊甸园空间执行GC后，存活的对象会被堆积在同一个幸存者空间。

4、当一个幸存者空间饱和，还在存活的对象会被移动到另一个幸存者空间。然后会清空已经饱和的哪个幸存者空间。

5、在以上步骤中重复N次（N = MaxTenuringThreshold（年龄阀值设定，默认15））依然存活的对象，就会被移动到老年代。

从上面的步骤可以发现，两个幸存者空间，必须有一个是保持空的。如果两个两个幸存者空间都有数据，或两个空间都是空的，那一定是你的系统出现了某种错误。

我们需要重点记住的是，对象在刚刚被创建之后，是保存在伊甸园空间的（Eden）。那些长期存活的对象会经由幸存者空间（Survivor）转存到老年代空间（Old generation）。

也有例外出现，对于一些比较大的对象（需要分配一块比较大的连续内存空间）则直接进入到老年代。一般在Survivor 空间不足的情况下发生。

一般是把 Java 堆分为新生代和老年代，这样就可以根据各个年代的特点采用最适当的收集算法。在新生代中，每次垃圾收集时都发现有大批对象死去，只有少量存活，那就选用复制算法，只需要付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保，就必须使用“标记—清理”或者“标记—整理”算法来进行回收。

# 垃圾收集器 #

## Serial收集器（串行收集器） ##

Serial 收集器是最基本、发展历史最悠久的收集器，曾经是虚拟机新生代收集的唯一选择。这是一个单线程的收集器，但它的“单线程”的意义并不仅仅说明它只会使用一个 CPU 或一条收集线程去完成垃圾收集工作，更重要的是在它进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。  
![在这里插入图片描述][2111b8e066a140059ee008a68127a4db.png]  
实际上到现在为止，它依然是虚拟机运行在 Client 模式下的默认新生代收集器。它也有着优于其他收集器的地方：简单而高效（与其他收集器的单线程比），对于限定单个 CPU 的环境来说，Serial 收集器由于没有线程交互的开销，专心做垃圾收集自然可以获得最高的单线程收集效率。

## ParNew收集器 ##

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括 Serial 收集器可用的所有控制参数（例如：-XX:SurvivorRatio、-XX:PretenureSizeThreshold、-XX:HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与 Serial 收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。ParNew 收集器的工作过程如下图所示。  
![在这里插入图片描述][6004ff936a24476db070b24cbfdf1b80.png]  
ParNew 收集器除了多线程收集之外，其他与 Serial 收集器相比并没有太多创新之处，但它却是许多运行在 Server 模式下的虚拟机中首选的新生代收集器，其中有一个与性能无关但很重要的原因是，除了 Serial 收集器外，目前只有它能与 CMS 收集器（并发收集器，后面有介绍）配合工作。

## Parallel Scavenge收集器 ##

Parallel Scavenge 收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器……看上去和 ParNew 都一样，那它有什么特别之处呢？

## CMS收集器 ##

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。  
1.初始标记（CMS initial mark）  
2.并发标记（CMS concurrent mark）  
3.重新标记（CMS remark）  
4.并发清除（CMS concurrent sweep）  
其中，初始标记、重新标记这两个步骤仍然需要"Stop The World"。初始标记仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行 GC RootsTracing 的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。

## G1收集器 ##

G1（Garbage-First）收集器是当今收集器技术发展的最前沿成果之一，G1 是一款面向服务端应用的垃圾收集器。  
并行与并发： G1 能充分利用多 CPU、多核环境下的硬件优势，使用多个CPU（CPU或者CPU核心）来缩短 Stop-The-World 停顿的时间，部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 Java 程序继续执行。

分代收集： 与其他收集器一样，分代概念在 G1 中依然得以保留。虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次 GC 的旧对象以获取更好的收集效果。

空间整合： 与 CMS 的“标记—清理”算法不同，G1 从整体来看是基于“标记—整理”算法实现的收集器，从局部（两个 Region 之间）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着 G1 运作期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次 GC 。

可预测的停顿： 这是 G1 相对于 CMS 的另一大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒，这几乎已经是实时 Java（RTSJ）的垃圾收集器的特征了。

阿里的这篇文章就讲的很好:

> https://zhuanlan.zhihu.com/p/73628158

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70]: /images/20220829/9c6366558c4d460da89e17f44df35319.png
[5d52ce9a6e094f80b9981d5c5b57b866.png]: /images/20220829/aac3b8e26e0642739ec0f8dc12b0ddd3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 1]: /images/20220829/c7b8e058a6054032bfc89745761ff867.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 2]: /images/20220829/2374ba4c9011449dafb9621f7a8d47dd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 3]: /images/20220829/3c1f13cebe4141b498cc031a8fa9ea3a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 4]: /images/20220829/24c6375808cb419ead0beb88b41d4815.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzU4NjcxMw_size_16_color_FFFFFF_t_70 5]: /images/20220829/4f5b525647f04747a012a01582d6002d.png
[2111b8e066a140059ee008a68127a4db.png]: /images/20220829/9eea5a82dd9a4655b1b25ef0f666dfed.png
[6004ff936a24476db070b24cbfdf1b80.png]: /images/20220829/57574c1da94f4309af840393b3b08fbd.png