JVM 垃圾回收

Posted 2022-12-12 chun_soft

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

要想进行垃圾回收，得先知道什么样的对象是垃圾。

1.1 引用计数法

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

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

例如：

public class Main 
    public static void main(String[] args) 
        MyObject object1 = new MyObject();
        MyObject object2 = new MyObject();
 
        object1.object = object2;
        object2.object = object1;
 
        object1 = null;
        object2 = null;
    

class MyObject
    public Object object = null;

最后面两句将object1和object2赋值为null，也就是说object1和object2指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数都不为0，那么垃圾收集器就永远不会回收它们。

1.2 可达性分析

为了解决相互引用问题，在Java中采取了可达性分析法。该方法的基本思想是通过一系列的“GC Roots”对象作为起点进行搜索，如果在“GC Roots”和一个对象之间没有可达路径，则称该对象是不可达的，不过要注意的是被判定为不可达的对象不一定就会成为可回收对象。

被判定为不可达的对象要成为可回收对象必须至少经历两次标记过程，如果在这两次标记过程中仍然没有逃脱成为可回收对象的可能性，则基本上就真的成为可回收对象了。最后面两句将object1和object2赋值为null，也就是说object1和object2指向的对象已经不可能再被访问，但是由于它们互相引用对方，导致它们的引用计数都不为0，那么垃圾收集器就永远不会回收它们。

Java并不采用引用计数法来判断对象是否已“死”，而采用“可达性分析”来判断对象是否存活。

此算法的核心思想：通过一系列称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索走过的路径称为“引用链”，当一个对象到 GC Roots 没有任何的引用链相连时(从 GC Roots 到这个对象不可达)时，证明此对象不可用。以下图为例：

对象Object5—Object7之间虽然彼此还有联系，但是它们到 GC Roots 是不可达的，因此它们会被判定为可回收对象。

在Java语言中，可作为GC Roots的对象包含以下几种：

1. 虚拟机栈(栈帧中的本地变量表)中引用的对象。(可以理解为：引用栈帧中的本地变量表的所有对象)；
2. 方法区中静态属性引用的对象(可以理解为:引用方法区该静态属性的所有对象)；
3. 方法区中常量引用的对象(可以理解为：引用方法区中常量的所有对象)
4. 本地方法栈中(Native方法)引用的对象(可以理解为：引用Native方法的所有对象)

可以理解为:

（1）首先第一种是虚拟机栈中的引用的对象，我们在程序中正常创建一个对象，对象会在堆上开辟一块空间，同时会将这块空间的地址作为引用保存到虚拟机栈中，如果对象生命周期结束了，那么引用就会从虚拟机栈中出栈，因此如果在虚拟机栈中有引用，就说明这个对象还是有用的，这种情况是最常见的。

（2）第二种是我们在类中定义了全局的静态的对象，也就是使用了static关键字，由于虚拟机栈是线程私有的，所以这种对象的引用会保存在共有的方法区中，显然将方法区中的静态引用作为GC Roots是必须的。

（3）第三种便是常量引用，就是使用了static final关键字，由于这种引用初始化之后不会修改，所以方法区常量池里的引用的对象也应该作为GC Roots。

（4）最后一种是在使用JNI技术时，有时候单纯的Java代码并不能满足我们的需求，我们可能需要在Java中调用C或C++的代码，因此会使用native方法，JVM内存中专门有一块本地方法栈，用来保存这些对象的引用，所以本地方法栈中引用的对象也会被作为GC Roots。

1.3 JVM之判断对象是否存活

首先看下，finalize()方法，它是Object中的方法，当垃圾回收器将要回收对象所占内存之前被调用，即当一个对象被虚拟机宣告死亡时会先调用它finalize()方法，让此对象处理它生前的最后事情（这个对象可以趁这个时机挣脱死亡的命运）。

即使在可达性分析算法中不可达的对象，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段，要真正宣告一个对象死亡，至少要经历再次标记过程。

标记的前提是对象在进行可达性分析后发现没有与GC Roots相连接的引用链。

• 1).第一次标记并进行一次筛选。
  筛选的条件是此对象是否有必要执行finalize()方法。
  当对象没有覆盖finalize方法，或者finzlize方法已经被虚拟机调用过，虚拟机将这两种情况都视为“没有必要执行”，对象被回收。

• 2).第二次标记
  如果这个对象被判定为有必要执行 finalize() 方法，那么这个对象将会被放置在一个名为：F-Queue的队列之中，并在稍后由一条虚拟机自动建立的、低优先级的Finalizer线程去执行。这里所谓的“执行”是指虚拟机会触发这个方法，但并不承诺会等待它运行结束。这样做的原因是，如果一个对象finalize（）方法中执行缓慢，或者发生死循环（更极端的情况），将很可能会导致F-Queue队列中的其他对象永久处于等待状态，甚至导致整个内存回收系统崩溃。
  Finalize（）方法是对象脱逃死亡命运的最后一次机会，稍后GC将对F-Queue中的对象进行第二次小规模标记，如果对象要在finalize（）中成功拯救自己----只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。

流程图如下：

2、垃圾收集算法

已经能够确定一个对象为垃圾之后，接下来要考虑的就是回收，怎么回收呢?
得要有对应的算法，下面看看常见的垃圾回收算法。

2.1 标记-清除(Mark-Sweep)

• 标记

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

此时堆中所有的对象都会被扫描一遍，从而才能确定需要回收的对象，比较耗时。

• 清除

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

缺点：
标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

（1）标记和清除两个过程都比较耗时，效率不高；
（2）会产生大量不连续的内存碎片，空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时，无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。

2.2 复制(Copying)

将内存划分为两块相等的区域，每次只使用其中一块，如下图所示：

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

缺点: 空间利用率降低。

2.3 标记-整理(Mark-Compact)

标记过程仍然与"标记-清除"算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

让所有存活的对象都向一端移动，清理掉边界以外的内存。

3、分代收集算法

既然上面介绍了3中垃圾收集算法，那么在堆内存中到底用哪一个呢?

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

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

4、垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现，说白了就是落地咯。

JVM client模式和Server模式的区别

我们把jdk安装完成后，在命名行输入java -version
不仅可以看到jdk版本相关信息，还会看到类似与 Java HotSpot™ 64-Bit Server VM (build 25.31-b07, mixed mode) 这样的信息。
其中有个Server VM (build 25.31-b07, mixed mode)其实代表了JVM的Server模式了。
当然JVM还有一个Client模式。

JVM Server模式与client模式启动的差别？
最主要的差别在于：-Server模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。

原因是：当虚拟机运行在-client模式的时候,使用的是一个代号为C1的轻量级编译器, 而-server模式启动的虚拟机采用相对重量级,代号为C2的编译器. C2比C1编译器编译的相对彻底，服务起来之后,性能更高。

所以通常用于做服务器的时候我们用服务端模式，如果你的电脑只是运行一下java程序，就客户端模式就可以了。当然这些都是我们做程序优化程序才需要这些东西的，普通人并不关注这些专业的东西了。其实服务器模式即使编译更彻底，然后垃圾回收优化更好，这当然吃的内存要多点相对于客户端模式。

4.1 Serial收集器

Serial收集器是最基本、发展历史最悠久的收集器，曾经(在JDK1.3.1之前)是虚拟机新生代收集的唯一选择。

它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。

优点：简单高效，拥有很高的单线程收集效率
缺点：收集过程需要暂停所有线程
算法：复制算法
适用范围：新生代
应用：Client模式下的默认新生代收集器

4.2 ParNew收集器

可以把这个收集器理解为Serial收集器的多线程版本。

优点：在多CPU时，比Serial效率高；
缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差；
算法：复制算法；
适用范围：新生代；
应用：运行在Server模式下的虚拟机中首选的新生代收集器。

4.3 Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量。

吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。

-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间， 
-XX:GCTimeRatio直接设置吞吐量的大小。

4.4 Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。

4.5 Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收。
吞吐量优先

4.6 CMS收集器

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

(1)初始标记 CMS initial mark    标记GC Roots能关联到的对象 Stop The World--->速度很快
(2)并发标记 CMS concurrent mark  进行GC Roots Tracing
(3)重新标记 CMS remark World    修改并发标记因用户程序变动的内容 Stop The World
(4)并发清除 CMS concurrent sweep

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

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

4.7 G1收集器

G1特点：
（1）并行与并发；
（2）分代收集(仍然保留了分代的概念)；
（3）空间整合(整体上属于“标记-整理”算法，不会导致空间碎片) 可预测的停顿(比CMS更先进的地方在于能让使用者明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒)。

使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个大小相等的独立区域(Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region(不需要连续)的集合。

每个region记录着两个top-at-mark-start（TAMS）指针，分别为prevTAMS和nextTAMS。在TAMS以上的对象就是新分配的，因而被视为隐式marked。通过这种方式我们就找到了在GC过程中新分配的对象，并把这些对象认为是活的对象。

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

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

最终标记(Final Marking)：修正并发标记阶段因为用户程序的并发导致变动的数据，需暂停用户线程。

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

4.8 垃圾收集器分类

• （1）串行收集器->Serial和Serial Old

只能有一个垃圾回收线程执行，用户线程暂停。适用于内存比较小的嵌入式设备。

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

多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。适用于科学计算、后台处理等若交互场景。

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

用户线程和垃圾收集线程同时执行(但并不一定是并行的，可能是交替执行的)，垃圾收集线程在执行的时候不会停顿用户线程的运行。

4.9 理解吞吐量和停顿时间

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

停顿时间越短就越适合需要和用户交互的程序，良好的响应速度能提升用户体验; 高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任 务。

小结：这两个指标也是评价垃圾回收器好处的标准，其实调优也就是在观察者两个变量。

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

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

4.11 再次理解G1

JDK 7开始使用，JDK 8非常成熟，JDK 9默认的垃圾收集器，适用于新老生代。
判断是否需要使用G1收集器?

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

4.12 如何开启需要的垃圾收集器

(1)串行 -XX:+UseSerialGC -XX:+UseSerialOldGC
(2)并行(吞吐量优先): -XX:+UseParallelGC -XX:+UseParallelOldGC
(3)并发收集器(响应时间优先) -XX:+UseConcMarkSweepGC -XX:+UseG1GC

查看服务器使用的垃圾收集器：

java -XX:+PrintCommandLineFlags -version