JVM之垃圾回收算法和垃圾回收器(大厂收割机)

活动地址：毕业季·进击的技术er

前言：

• 很多天没发文章了，最近笔者比较忙，没有时间从0开始写一篇文章，就发一篇自己做的笔记吧。
• 关于JVM垃圾回收器的，涉及到的知识点可能会比较广和有一定的深度，该篇笔记是结合马士兵教程视频、周志明《深入理解JAVA虚拟机》、JVM官方文档、网上的其他资料等，在此特别感谢各位前辈们，能够站在各位前辈们的肩膀上学习是我的荣幸，也期望笔者今后也能成功这样的前辈。
• 读者可能会在阅读过程中遇到不懂的名词，这个时候可以自行查阅资料哈，比如三色标记算法，笔者就没有进行详细的阐述，因为是个人笔记，某些知识点感觉印象已经非常深刻，就一笔带过了，望见谅。

1.常见的垃圾回收算法：

1.1确定某个对象是垃圾的算法：

1.1.1引用计数法（无法解决循环引用，a指向b，b指向c，c指向a，但是a、b、c都不是根对象）

• 在java中我们不适用这个算法，使用的是根可达性算法。
• python中使用的是这个算法，这可能也是它的性能不如java的原因之一。

1.1.2根可达性算法(三色标记算法)

• 三种颜色

  • 白色：没有检查（或者检查过了，确实没有引用指向它了）
  • 灰色：自身被检查了，成员没被检查完（可以认为访问到了，但是正在被检查，就是图的遍历里那些在队列中的节点）
  • 黑色：自身和成员都被检查完了

• 假设现在有白、灰、黑三个集合（表示当前对象的颜色），其遍历访问过程为：

  • 初始时，所有对象都在 【白色集合】中；
  • 将GC Roots 直接引用到的对象 挪到 【灰色集合】中；
  • 从灰色集合中获取对象：
    1. 将本对象 引用到的 其他对象 全部挪到 【灰色集合】中；
    2. 将本对象 挪到 【黑色集合】里面。
  • 重复步骤3，直至【灰色集合】为空时结束。
  • 结束后，仍在【白色集合】的对象即为GC Roots 不可达，可以进行回收。

• 什么是根？根就可以理解为main方法，你main方法就是根，你这这里new出来的对象

  • 

    • 通过System Class Loader或者Boot Class Loader加载的class对象(通过自定义类加载器加载的class不一定是GC Root)
    • 处于激活状态的线程
    • 栈中的对象
    • JNI栈中的对象
    • JNI中的全局对象
    • 正在被用于同步的各种锁对象
    • JVM自身持有的对象，比如系统类加载器等。

1.2垃圾回收算法

• 标记清除（Mark-Sweep）

  • 缺点：
  • 1.造成内存碎片化 ；
  • 2 .分配效率较低，如果是一块连续的内存空间，那么我们可以通过指针加法（pointer bumping）来做分配。而对于空闲列表，Java 虚拟机则需要逐个访问列表中的项，来查找能够放入新建对象的空闲内存。

• 标记压缩(标记清除的升级)（Mark-Compact）

  • 能够解决碎片化问题，但是压缩算法的性能开销是比较大的，因为需要挪动对象，然后改变对象引用的地址。

• 复制算法（Coping）

  • 能够解决碎片化问题，但是空间使用效率变低了，毕竟有一块空间是用不着的。
  • 复制算法是将内存划分为两个区间，在任意时间点，所有动态分配的对象都只能分配在其中的一个区间（称为活动区间），而另外一个区间（空闲区间）是空闲的。
  • 当有效内存空间耗尽时，JVM将暂停程序运行，开启复制GC线程。接下来GC线程会将活动区的存活对象，全部复制到空闲区间，且严格按照内存地址依次排列，与此同时，GC线程将更新存活对象的内存引用地址指向新的内存地址。
  • 此时，空闲区间已经与活动区间交换，而垃圾对象现在已经全部留在了原来的活动区间，也就是现在的空闲区间。事实上，在活动区间转换为空闲区间的同时，垃圾对象已经被一次性全部回收了。

三种算法在垃圾回收器中搭配使用。

2.常用的垃圾回收器

目前的垃圾回收器总共十种：

其中serial和serial old有stop the world 简称stw，即停止其他业务线程，只进行垃圾回收线程的执行；并且是单线程的。

serial是单线程的，如下：

ps和po是多线程的，如下图：

ParNew与ps、po区别不大，也是并行的，并且也是stw的，只是ParNew能搭配CMS进行垃圾回收

CMS如下：(初始标记和重新标记是STW的)

• 初始标记是找到根对象

• 并发标记：这个过程业务线程和垃圾回收线程可以同事执行

  在这个过程中，使用三色标记算法，但是存在这样一种可能：

  • ​ 三色：黑色（全部子引用对象都遍历过）、灰色（正在遍历，只遍历了部分子引用对象）、白色（还未遍历过其子引用对象）
  • 当我们正要遍历灰色对象的子引用时（子引用还是白色）这个时候我们突然切断灰色对象与子引用之间的引用，然后让这个白色对象成为其它标记为了黑色的对象的子对象，这个时候可能会造成误回收。
  • 所以我们会存在重复标记

• 重复标记：这个过程是STW的，即让其他业务线程停止一小会，进行垃圾回收，当然这个过程肯定是要比serial和serial old一开始就进行STW要快的。

• 最后就是并发的清理垃圾对象

G1 在逻辑上分区，在物理上是不分区的，物理上分成了一个一个的小Region

G1，采用了concurrent marking cycle：

• 初始标记（Initial Marking）：标记一下GC Roots能直接关联到的对象，伴随着一次普通的Young GC发生，并修改NTAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，此阶段是stop-the-world操作。
  根区间扫描，标记所有幸存者区间的对象引用，扫描 Survivor到老年代的引用，该阶段必须在下一次Young GC 发生前结束。
• 并发标记（Concurrent Marking）：是从GC Roots开始堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行，该阶段可以被Young GC中断。
• 最终标记（Final Marking）：是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，此阶段是stop-the-world操作，使用snapshot-at-the-beginning (SATB) 算法。
• 筛选回收（Live Data Counting and Evacuation）：首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划,回收没有存活对象的Region并加入可用Region队列。这个阶段也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户可控制的，而且停顿用户线程将大幅提高收集效率。

G1在Java9中成了JVM中默认的垃圾收集器。

ZGC采用了颜色指针，如下：

ZGC在Java11开始崭露头角，在Java15转正，成为了JVM默认的垃圾回收器。

全部总结如下：

3.经常说的GC

• MinorGC (Young GC)

  • 当年轻代空间不足时，就会触发MinorGC，这里的年轻代满指的是Eden区满，Survivor满不会引发GC。（每次Minor GC会清理年轻代的内存。）因为Java对象大多都具备朝生夕灭的特性，所以Minor GC非常频繁，一般回收速度也比较快。
  • Minor GC会引发STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。
  • Minor GC后Eden区是空的，会把Eden中的所有活的对象都移到Survivor区域中，如果Survivor区中放不下，那么剩下的活的对象就被移到Old generation 中。

• Major GC（Old GC）

  • 指发生在老年代的GC，对象从老年代消失时，只有CMS回收器有单收集Old区行为

• Full GC

  • 整堆收集，收集整个Java堆和方法区的垃圾收集触发

  • Full GC执行的情况有如下五种：

    • 调用System.gc()时，系统建议执行Full GC，但是不必然执行

    • 老年代空间不足

    • 方法区空间不足 (永久代或者元空间)

    • 通过Minor GC后进入老年代的平均大小大于老年代的可用内存

    • 由Eden区、survivor spacee（From Space）区向survivor spacel（To Space）区复制时，survivor 区空间不足，对则把该对象转存到老年代，如果老年代的可用内存小于该对象大小，就会触发Full GC

  • Full GC 是开发或调优中尽量要避免的。这样暂时时间会短一些，Major GC 和 Full GC出现STW的时间，是Minor GC的10倍以上

• Mixed GC

  • G1垃圾回收器所独有的GC方式。
  • G1在什么时候会触发Mixed GC 参数： -XX:InterfaceTestControllernitiatingHeapOccupancyPercent ，他的默认值是45% 。 意思就是说如果老年代占用超过了45% ， 就会触发一个叫做混合回收的操作 ， 混合回收意味着新生代和老年代一起回收，这时候毫无疑问整个系统线程都会停止。
  • 选定所有Eden Region和全局并发标记计算得到的收益较高的部分Old Region放入CSet，使用多线程复制算法将CSet的存活对象复制到Survivor Region或者晋升到Old Region。

4.G1相较于之前的垃圾回收器解决了一些问题（重难点）

4.1card table 卡表和RSet解决跨代引用

在CMS中有Rset的概念，但是是在老年代中。

• 在CMS中，也有RSet的概念，在老年代中有一块区域用来记录指向新生代的引用。这是一种point-out，在进行Young GC时，扫描根时，仅仅需要扫描这一块区域，而不需要扫描整个老年代。
• 但在G1中，并没有使用point-out，这是由于一个分区太小，分区数量太多，如果是用point-out的话，会造成大量的扫描浪费，有些根本不需要GC的分区引用也扫描了。
• 于是G1中使用point-in来解决。point-in的意思是哪些分区引用了当前分区中的对象。这样，仅仅将这些对象当做根来扫描就避免了无效的扫描。

总结就是我们需要用到G1中分区Region，尽量进行精确查找找到Region。（CMS中引用都是存在一起的，每次都需要遍历老年代那块区域中所有的引用）

如下是G1的卡表和 Rset示意图：

Rset(rember set)：每个region对应一个RSet，这个数据结构里记录了哪些其他region包含了指向这个region的对象的引用；这个RSet记录的是从别的region指向该region的card。所以这是一种“points-into”的Remembered Set。

（key经过hash计算进行散列来确定在Card Tble中的位置，然后再这个card table块中具体查找region，就和hashmap中key value的查找类似）

Card Table：

• 需要注意的是，如果引用的对象很多，赋值器需要对每个引用做处理，赋值器开销会很大，为了解决赋值器开销这个问题，在G1中又引入了另外一个概念，卡表（Card Table）。一个Card Table将一个分区在逻辑上划分为固定大小的连续区域，每个区域称之为卡。卡通常较小，介于128到512字节之间。Card Table通常为字节数组，由Card的索引（既数组下标）来标识每个分区的空间地址。
• 默认情况下，每个卡都未被引用。当一个地址空间被引用时，这个地址空间对应的数组索引的值被标记为“0”，既标记为被引用，此外RSet也将这个数组下标记录下来。一般情况下，这个RSet其实是一个Hash Table，key是别的Region的起始地址，Value记录了他们之间的引用关系。

4.2 SATB解决新创建对象漏标问题

TAB全称Snapshot-At-The-Beginning，SATB算法机制中，会在GC开始时先创建一个对象快照，在并发标记时所有快照中当时的存活对象就认为是存活的，标记过程中新分配的对象也会被标记为存活对象，不会被回收。这种机制能够很好解决新创建对象漏标的情况。STAB核心的两个结构就是两个Bitmap。

Bitmap分别存储在每个Region中，并发标记过程里的两个重要的变量：preTAMS(pre-top-at-mark-start，代表着Region上一次完成标记的位置) 以及nextTAMS（next-top-at-mark-start，随着标记的进行会不断移动，一开始在top位置）。SATB通过控制两个变量的移动来进行标记，移动规则如下：

• 假设第n轮并发标记开始，将该Region当前的Top指针赋值给nextTAMS，在并发标记标记期间，分配的对象都在**[ nextTAMS, Top ]**之间，SATB能够确保这部分的对象都会被标记，默认都是存活的。
• 当并发标记结束时，将nextTAMS所在的地址赋值给previousTAMS，SATB给**[ Bottom, previousTAMS ]**之间的对象创建一个快照Bitmap，所有垃圾对象能通过快照被识别出来。
• 第n+1轮并发标记开始，过程和第n轮一样。

如下示意图显示了两轮并发标记的过程：

• A阶段，初始标记阶段，需要STW，将扫描Region的Top值赋值给nextTAMS。
• A-B阶段：并发标记阶段。
• B阶段，并发标记结束阶段，此时并发标记阶段生成的新对象都会被分配在[nextTAMS，Top]之间，这些对象会被定义为“隐式对象”，同时_next_mark_bitmap也开始存储nextTAMS标记的对象的地址。
• C阶段，清除阶段，_next_mark_bitmap和_prev_mark_bitmap会进行交换，同时清理**[ Bottom, previousTAMS ]**之间被标记的所有对象，对于“隐式对象”会在下次垃圾收集过程进行回收（如第F步），这也是SATB存在弊端，会一定程度产生未能在本次标记中识别的浮动垃圾。

4.3pre-write barrier解决对象引用被修改产生漏标的问题

千万不要把这个读屏障、写屏障和Java内存模型里面的读屏障搞混了，两者根本不是同一个东西，在G1中的写屏障，像是一种AOP技术，在字节码层面或者编译代码层面给写操作增加一个额外的处理。同理在ZGC中的读屏障也如此，在字节码层面或者编译代码层面给读操作增加一个额外的处理。

栅栏（屏障）是指在原生代码片段中，某些语句执行前，栅栏（屏障）代码也会执行。

G1主要是在写前栅栏（屏障）（pre-write barrier）和写后（屏障）（post-write barrier）。事实上，写栅栏的指令序列开销非常昂贵，应用吞吐量也会根据栅栏复杂度而降低。

• pre-write barrier：在执行赋值时，等式左边引用会变更到另外一个对象上，这样原来等式右边对象将失去一个引用。那么G1的JVM会记录这个失去引用的对象。JVM并不会马上更新RSet，而是等批量操作，再将来更新RSet。

• post-write barrier：在执行赋值后，等式右侧的对象将获得一个新的引用，这个对象所在region的RSet应该更新。为了提高性能，jvm也只是记录该更新日志，等后面批操作来更新RSet

Pre-Write Barrier和Post-Write Barrier 作用的对象不同，前者是针对三色标记算法的缺陷，后者是针对Card Table

SATB利用pre-write barrier，将所有即将被修改引用关系的白颜色对象旧引用记录下来，最后以这些旧引用为根重新扫描一遍，以解决白对象引用被修改产生的漏标问题。

在引用修改时把原引用保存到satb_mark_queue中，每个线程都自带一个satb_mark_queue。在下一次的并发标记阶段，会依次处理satb_mark_queue中的对象，确保这部分对象在本轮GC中是存活的。

如果被修改引用的白对象就是要被收集的垃圾，这次的标记会让它躲过GC，这就是float garbage。因为SATB的做法精度比较低，所以造成的float garbage也会比较多。

活动地址：毕业季·进击的技术er