jvm的轻量级爽口讲解--内存管理子系统(俗称垃圾回收)〇叁

前情提要

jvm的轻量级爽口讲解–内存管理子系统(俗称垃圾回收)〇贰

其中对象的引用链路描述有误,现已经更改(应该是查找根节点引用的对象,而不是查找引用根节点的对象)

前言

1
2
3
4
hey!guys,I'm back,关于之前两篇的blog,博主尽可能进行debug,毕竟一篇好的blog是需要经过不断修改打磨的,
就像我们敲过的代码,如果不去不断的重构,之后必将"积重难返",然后还有一个,关于图片显示的问题,这个博主也
正在全力解决当中,准备把图床转到国内(此行为需要备案),域名正在备案中.......请大家耐心等待。好了我们继续上一
篇的问题,上一篇我们留下一个关键的问题,如何进行垃圾内存的并发标记,这次,我们就从这个问题开始。

再聊并发可达性分析

上一篇关于并发可达性问题,我们只是简单的一笔带过,这次我们利用对象图,帮我们把问题描述的更加清晰一些,以便于更加清晰的理解和解决。首先我们先对对象在对象图中的颜色进行区分定义:

  • 白色:表示对象还没有被垃圾回收器访问过,也没有被标记过。
  • 黑色:表示对象已经被访问且标记为安全存活对象(即不是垃圾对象),不会再进行扫描。
  • 灰色:表示对象已经被访问,但是此对象所引用的其他对象至少有一个还没有被扫描过。只有灰色对象所引用的白色对象扫描完毕,其才能被标记为黑色对象,所以说在标记过程中, 黑色对象不能直接指向白色对象

好的,我们看一下标记过程的抽象图:
初始过程,黑色的方框对象为根节点,开始向下查找。

memory_sign1
中间标记过程,就像是波纹~~(dio:纳尼?)~~一样,以灰色对象为波峰持续推进

memory_sign2
最后直到所有的灰色对象都查找不到引用,将最后这批灰色对象标记为黑色。

memory_sign3
好了,正常的标记过程就是如此,但如果有用户线程来捣乱,那就不一样了

那用户线程如何捣乱呢?把正在查找的灰色对象对白色对象切断?我们先试一下,以下虚线为切断的引用

memory_sign4
好像结果并没有什么阻碍,最终查找的结果是正确的,因为用户已经切断了引用,而我们的标记结果也实时作出了改变。

那么添加黑色对象对已经查找的白色对象的引用呢?

memory_sign5
也同样的不会出现什么问题,最后的结果和原来一致,那么,如果两个同时叠加呢?

memory_sign6
唉?问题就出来了,如果我们切断灰色对象对白色对象的引用,然后用一个黑色对象引用此白色对象,会让这个白色对象到扫描的最后都不会标记为黑色,但他有黑色对象的引用,照这样的标记回收会使我们的回收掉本应该存活的对象。

现在,我们知道,要是并发收集出现错误,必须满足以下两个条件:

  • 切断从灰色对象到黑色对象的引用
  • 添加已经扫描过的黑色对象对白色对象的引用

只要我们破坏其中一个条件,并发标记便可以实现。

破坏第一个条件,当探测到切断灰色对象对白色对象的引用,把这个引用记录下来,然后再以记录过的灰色对象为根节点,再扫描一遍,这种方法叫做原始快照

破坏第二个条件,当添加黑色对象到白色对象的引用时,我们将这个黑色对象重置为灰色对象,再进行查找。这种方法叫做增量更新
CMS收集器是基于增量更新来做并发标记的,G1、shennandoah则是用原始快照来实现的,这些收集器,会在之后进行专门的一一讲解。

再聊谁实现

好了讲了这么多的理论,我们该讲讲实现了,其实还有一些理论还没有涉及,笔者会在下面以及后几篇补上,现在感觉理论比较枯燥,我们还是聊聊实际的吧。

接下来我们会聊到一些垃圾收集器,以及垃圾收集器所用到的之前的理论部分。

首先,我们先为垃圾收集器进行分类,Serial、ParNew,Parallel Scavenge,Serial Old,Parallel Old,CMS收集器,笔者称他们为经典的收集器,因为这些收集器都是专门管理新生代,或者老年代的。

而之后出现的G1,shennandoah,ZGC收集器,都是新生代,老年代并用的。

而 jdk11出现的Epsilon收集器比较特殊,它不做任何回收动作~~(我要你有何用?)~~,至于其作用笔者会在之后描述。

目前我们只聊了聊经典收集器的理论,所以我们从经典的收集器开始聊起,

  • Serial 收集器(直译是电视连续剧?重在连续这个词)最早出现的垃圾回收器,它适用于单核的CPU,因此特别适合运行客户端方面的应用,虽然在之后的回收器层出不穷,但是在客户端应用方面,Serial收集器一直最低内存消耗发挥着作用。
    * ParNew 收集器,专管新生代的多线程收集器JDK1.3
  • Parallel Scavenge ParNew 收集器的进阶版一般Par开头的,都是多线程收集器,这款收集器主打可控的吞吐量,吞吐量?好像是一个新概念,没错,之前我们讲过,停顿时间是衡量垃圾回收性能的重要指标之一,另一个指标便是吞吐量,他是指用户运行时间在整个程序总运行时间(用户运行时间和垃圾回收时间)的占比。他有自己的参数JDK1.4
  • Serial Old 收集器 Serial收集器的老年代版本
  • Parallel Old 收集器专门管理老年代的收集器,在此收集器出现之前ParNew 收集器一直初一比较尴尬的境地,因为作为多线程的新生代收集器,他却只能与单线程的Serial 配合使用JDK6
  • CMS 划时代意义的收集器,我们之前所说的并发回收就是从这个收集器开始的,之前的所有收集器,都只能通过停顿其他用户线程进行标记和回收,但是他是老年代的收集器,其次,作为老年代的收集器,它却无法配合Parallel Scavenge使用。

以上就是对我们所讲的理论支撑的垃圾回收器的简单介绍,那我们怎么使用他们呢?
很简单,只要启动java的时候加入配置参数就好

1
java  -XX:+回收器参数   运行的Main类

那么下面给出的回收器参数

参数 描述
UseSerialGC 使用Serial + Serial Old 收集器
UseParNewGC 使用ParNew + Serial Old 收集器
UseConcMarkSweepGC 使用ParNew + CMS+Serial Old 的收集器组合进行回收 ,如果CMS收集器并发收集失败,会切换到Serial Old 收集器
UseParallelGC 使用Parallel Scavenge + Serial Old 收集器
UseParallelOldGC 使用 Parallel Scavenge + Parallel Old 收集器

这是我们目前可以通过参数切换到的收集器参数,我们会在下一篇blog,将参数写的更详尽一些,包括一些收集器的配置参数,和JDK9之后的从参数改变。

再聊一下停顿

我们前面聊了聊并发标记是如何实现的,现在我们聊一下如何让用户线程停顿,为什么要讲这个?因为可能会出现停顿时间异常的现象,如果我们不懂其中的原理将没有办法定位问题所在。

首先我们先退一步,上一篇博客,我们讲到GC ROOT 其中有很多类型的引用都会被作为GC ROOT,那么随着应用的体量的增大,引用数量必定猛增不减,这种时候我们如果在垃圾回收的时候,再去查询GC ROOT的引用,

那必然是不行的,因此,我们需要先整一个数据结构,在类型加载的时候,就把相关的引用写入数据结构中,这样我们不必在海量的引用中查找,只取数据结构里面的数据便可,JVM最经典的HotSpot虚拟机就是利用OopMap数据结构这样进行工作的

好了,GC Root的收集问题得到解决了,但是运行过程当中,引用关系肯定会改变,而JVM指令当中,大部分的指令都会造成引用关系的改变,我们不可能在每条指令后面都加一个OopMap结构,那对回收来说,空间成本将会变得额外的高昂。

因此,存储了OopMap数据结构外,在运行时,JVM会选择某些“特殊的位置”来记录引用信息,这些特殊的位置就叫做安全点,那么安全点应该如何设置呢?

安全点设置既不能太少而使回收程序等待时间过长,又不能太多增大程序运行负荷,因此安全点一般选在可长时间执行的地方,一般在方法调用、循环跳转、异常跳转等这些可以指令序列复用的地方。

简单总结一下问题

  • 如何做到并发可达性分析,方法分为哪几种?
  • 前期新生代,老年代分开管理的回收器都有那些?
  • 安全点是什么?一般在哪里设置