[Java知识库]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如下，采用了concurrent marking cycle：(初始标记和重新标记是STW的)

• 初始标记是找到根对象

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

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

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

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

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

G1 在逻辑上分区，在物理上是不分区的，物理上分成了一个一个的小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.垃圾回收中一些问题的解决（重难点）

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