GC(垃圾回收，Garbage Collect)

自动回收垃圾机制就是寻找Java堆中的对象，并对对象进行分类判别，寻找处正在使用的对象和已经不会使用的对象，然后把那些不会使用的对象从堆上清除

1 如何确定一个对象是垃圾？

1.1 引用计数法

​ 对于某个对象而言，只要应用程序中持有该对象的引用，就说明该对象不是垃圾，如果一个对象没有任何指针对其引用，它就是垃圾

弊端：如果AB相互持有引用，导致永远不能被回收

1.2 可达性分析

通过GC Root的对象，开始向下寻找，看某个对象是否可达

能作为GC Root：类加载器、Thread、虚拟机栈的本地变量表、static成员、常量引用、本地方法栈的变量等

2 什么时候会垃圾回收

1. 当Eden区或S区不够用了
2. 老年代空间不够用了
3. 方法区空间不够用了
4. System.gc()

3 垃圾收集算法

3.1 标记-清除(Mark-Sweep)

• 标记

找出内存中需要回收的对象，并把它们标记出来

• 清除

清除掉被标记需要回收的对象，释放出对应的内存空间

缺点：

1. 标记和清除两个过程都比较耗时，效率不高
2. 会产生大量不连续的内存碎片

3.2 标记-复制(Mark-Copying)

将内存划分为两块相等的区域，每次只使用其中一块

当其中一块内存使用完了，将还存活的对象复制到另一块上面，然后把已经使用过的内存空间一次清除掉

缺点：空间利用率降低

3.3 标记-整理(Mark-Compact)

标记过程和“标记-清除”算法一样，但接下来是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存

4 分代收集算法

Young区：复制算法(对象在被分配之后，可能生命周期比较短，Young区复制效率比较高)

Old区：标记清除或标记整理(Ole区对象存活时间比较长，没有必要复制，做个标记再清理)

5 垃圾收集器

5.1 Serial

​ Serial收集器是一种单线程收集器，只会使用一个CPU或者一条收集线程去完成垃圾收集工作，在进行垃圾收集的时候需要暂停其他线程

优点：简单高效，拥有很高的单线程收集效率

缺点：收集过程需要暂停所有线程

算法：复制算法

适用范围：新生代

应用：Client模式下的默认新生代收集器

5.2 Serial Old

​ Serial Old收集器也是一个单线程收集器，采用标记-整理算法，运行过程和Serial收集器一样

5.3 ParNew

Serial收集器的多线程版本

优点：在多CPU时，比Serial效率高

缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差

算法：复制算法

适用范围：新生代

应用：运行在Server模式下的虚拟机中首选的新生代收集器

5.4 Parallel Scavenge

​ Parallel Scavenge使用复制算法的收集器，是并行的多线程收集器，更关注系统的吞吐量

若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务

5.5 Parallel Old

​ Parallel Old收集器使用多线程和标记-整理算法进行垃圾回收，也更关注系统的吞吐量

5.6 CMS

​ CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。采用的是标记-清除算法，整个过程分为4步：

1. 初始标记 CMS：标记GC Roots直接关联对象，不用Tracing，速度很快
2. 并发标记 CMS：进行GC Roots Tracing
3. 重新标记 CMS：修改并发标记因用户程序变动的内容
4. 并发清除 CMS：清除不可达对象回收空间，同时有新垃圾产生，留着下次清理，称为浮动垃圾

并发标记和并发清除，收集器线程可以与用户一起工作

优点：并发收集、低停顿

缺点：产生大量空间碎片、并发阶段会降低吞吐量

5.7 G1(Garbage-First)

G1将整个Java堆划分为多个大小相等的独立区域(Region)，新生代和老年代不再是物理隔离嘞，都是一部分Region(不需要连续)的集合

每个Region大小都是一样的，可以是1M到32M之间的数值，但是必须保证是2的n次幂

所谓G1，其实就是优先回收垃圾最多的Region区域，属于标记-整理算法，不会导致空间碎片

​ 将空间在物理上随即划分为等大的Region，每块Region会被打上Eden或Survivor或Old的标签，在逻辑上，这些被打上标签的块构成了Eden区、Survivor区以及Old区。当GC运行时，G1会回收空闲空间最多的Region(不是每块Region都会被塞满，有些没有塞满)

工作过程可以分为以下几步：

初始标记（Initial Marking）：标记一下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程

并发标记（Concurrent Marking）：从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行

最终标记（Final Marking）：修改在并发标记阶段因为用户程序并发执行导致变动的数据，需要暂停用户线程

筛选回收（Live Data Counting and Evacuation）：对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

5.8 ZGC

JDK11引入的收集器，其不存在新老年代的概念，会分为一个个page，当进行GC操作时会对page进行压缩，没有碎片问题

1. 可以达到10ms以内的停顿时间要求
2. 支持TB级别的内存
3. 堆内存变大后停顿时间还在10ms以内

5.9 垃圾收集器分类

• 串行收集器 -> Serial和Serial Old

只能有一个垃圾回收线程执行，用户线程暂停

适用于内存比较小的嵌入式设备

• 并行收集器[吞吐量优先] -> Parallel Scanvenge、Parallel Old

多条垃圾收集线程并发工作，但此时用户线程任然处于等待状态

适用于科学计算、后台处理等交互场景

• 并发收集器[停顿时间优先] -> CMS、G1

垃圾收集线程在执行的时候不会停顿用户线程的运行

适用于相对时间有要求的场景

5.10 常见问题

• 吞吐量和停顿时间

  • 停顿时间->垃圾回收器进行垃圾回收终端应用执行响应的时间
  • 吞吐量->运行用户代码时间/(运行用户代码时间 + 垃圾搜集时间)

  停顿时间越短越适合需要和用户交互的程序

  高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务

• 如何选择合适的垃圾收集器

  • 优先调整堆的大小让服务器自己来选择
  • 如果内存小于100M，使用串行收集器
  • 如果是单核，并且没有停顿时间要求，使用串行或JVM自己选
  • 如何允许停顿时间超过1s，选择并行或JVM自己选
  • 如果响应时间最重要，并且不能超过1s，使用并发收集器

• 对于G1收集

  • JDK 9 默认的垃圾收集器，适用于新老生代
  • 是否使用G1收集器？

  1. 50%以上的堆被存活对象占用
  2. 对象分配和晋升的速度变化非常大
  3. 垃圾回收时间比较长

• G1中的RSet

  • 记录维护Region中对象的引用关系，用一个类似于hash的结构，key记录region的地址，value表示引用该对象的集合，这样就能知道该对象被哪些老年代的对象所引用，从而不能回收