JVM--15---垃圾回收相关算法 1---- 标记阶段算法、 finalization机制、MAT 与 JProfiler

---

垃圾回收相关算法

• 标记阶段—-引用计数算法
• 标记阶段—-可达性分析算法

---

• 清除阶段—-标记-清除算法
• 清除阶段—-复制算法
• 清除阶段—-标记-整理算法

---

• 分代收集算法
• 增量收集算法
• 分区算法

1. 标记阶段：引用计数算法

定义:

• 在堆里存放着几乎所有的 Java 对象实例，在 GC执行垃圾回收之前，首先需要区分出内存中哪些是存活对象，哪些是已经死亡的对象。只有被标记为己经死亡的对象，GC 才会在执行垃圾回收时，释放掉其所占用的内存空间，因此这个过程我们可以称为垃圾标记阶段。

JVM 中究竟是如何标记一个死亡对象呢？

判断对象存活一般有两种方式：引用计数算法和可达性分析算法。

当一个对象已经不再被任何的存活对象继续引用时，就可以宣判为已经死亡。

引用计数算法----实现方式

• 引用计数算法（Reference Counting）比较简单，对每个对象保存一个整型的引用计数器属性。用于记录对象被引用的情况。
• 对于一个对象 A，只要有任何一个对象引用了 A，则 A 的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象 A 的引用计数器的值为0，即表示对象 A 不可能再被使用，可进行回收。

优点：

• 实现简单，垃圾对象便于辨识；判定效率高，回收没有延迟性。

缺点：

• 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。
• 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。
• 引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在 Java 的垃圾回收器中没有使用这类算法。

循环引用

当 p 的指针断开的时候，内部的引用形成一个循环，这就是循环引用，从而造成内存泄漏

public class RefCountGC {
    // 这个成员属性的唯一作用就是占用一点内存
    private byte[] bigSize = new byte[5*1024*1024];
    // 引用
    Object reference = null;

    public static void main(String[] args) {
        RefCountGC obj1 = new RefCountGC();
        RefCountGC obj2 = new RefCountGC();
        obj1.reference = obj2;
        obj2.reference = obj1;
        obj1 = null;
        obj2 = null;
        // 显式的执行垃圾收集行为
        //这里发生GC，obj1和obj2能否被回收？
        System.gc();
    }
}

小结

引用计数算法，是很多语言的资源回收选择，例如因人工智能而更加火热的 Python，它更是同时支持引用计数和垃圾收集机制。

• 具体哪种最优是要看场景的，业界有大规模实践中仅保留引用计数机制，以提高吞吐量的尝试。
• Java 并没有选择引用计数，是因为其存在一个基本的难题，也就是很难处理循环引用关系。

Python 如何解决循环引用？

1. 手动解除：很好理解，就是在合适的时机，解除引用关系。
2. 使用弱引用 weakref，weakref 是 Python 提供的标准库，旨在解决循环引用。

2. 标记阶段：可达性分析算法

• 可达性分析算法 也叫 (或根搜索算法、追踪性垃圾收集)

概念:

相对于引用计数算法而言，可达性分析算法不仅同样具备实现简单和执行高效等特点，更重要的是该算法可以有效地解决在引用计数算法中循环引用的问题，防止内存泄漏的发生。

• 相较于引用计数算法，这里的可达性分析就是 Java、C# 选择的。这种类型的垃圾收集通常也叫作追踪性垃圾收集（Tracing Garbage Collection）

实现方式:

所谓 “GC Roots” 根集合就是一组必须活跃的引用。

基本思路：

1. 可达性分析算法是以根对象集合（GC Roots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达。
2. 使用可达性分析算法后，内存中的存活对象都会被根对象集合直接或间接连接着，搜索所走过的路径称为引用链（Reference Chain）
3. 如果目标对象没有任何引用链相连，则是不可达的，就意味着该对象己经死亡，可以标记为垃圾对象。
4. 在可达性分析算法中，只有能够被根对象集合直接或者间接连接的对象才是存活对象。
   

这里需要注意的是，可达性分析算法中，每次标记的是直接或间接与 GC Roots 连接的对象

标记完成后，遍历整个内存空间，将没有被标记的对象删除

Java 中 GC Roots 可以是哪些？

1. 虚拟机栈中引用的对象
   比如：各个线程被调用的方法中使用到的参数、局部变量等。
2. 本地方法栈内 JNI（通常说的本地方法）引用的对象
3. 方法区中类静态属性引用的对象
   比如：Java 类的引用类型静态变量
4. 方法区中常量引用的对象
   比如：字符串常量池（String Table）里的引用
5. 所有被同步锁 synchronized 持有的对象
6. Java 虚拟机内部的引用。
   基本数据类型对应的 Class 对象，
   一些常驻的异常对象（如：NullPointerException、OutOfMemoryError）
   系统类加载器等。
7. 反映 Java 虚拟机内部情况的 JMXBean、JVMTI 中注册的回调、本地代码缓存等。
   
   总结一句话就是，堆空间外的一些结构，比如虚拟机栈、本地方法栈、方法区、字符串常量池等地方对堆空间进行引用的，都可以作为 GC Roots 进行可达性分析

小技巧

• 由于 Root 采用栈方式存放变量和指针，所以如果一个指针，它保存了堆内存里面的对象，但是自己又不存放在堆内存里面，那它就是一个Root。

注意:

如果要使用可达性分析算法来判断内存是否可回收，那么分析工作必须在一个能保障一致性的快照中进行。这点不满足的话分析结果的准确性就无法保证。

• 这点也是导致 GC 进行时必须“Stop The World”的一个重要原因。
• 即使是号称（几乎）不会发生停顿的 CMS 收集器中，枚举根节点时也是必须要停顿的。

3. 对象的 finalization机制

概念：

• Java 语言提供了对象终止（finalization）机制来允许开发人员提供对象被销毁之前的自定义处理逻辑。

当垃圾回收器发现没有引用指向一个对象，即：垃圾回收此对象之前，总会先调用这个对象的 finalize() 方法。

finalize() 方法允许在子类中被重写

用于在对象被回收时进行资源释放。通常在这个方法中进行一些资源释放和清理的工作，比如

• 关闭文件
• 套接字
• 和数据库连接等。

注意：

永远不要主动调用某个对象的 finalize() 方法

永远不要主动调用某个对象的 finalize() 方法，应该交给垃圾回收机制调用。理由包括下面三点：

• 在 finalize() 时可能会导致对象复活。

• finalize() 方法的执行时间是没有保障的，它完全由 GC 线程决定，极端情况下，若不发生 GC，则 finalize()方法将没有执行机会。

• 一个糟糕的 finalize() 会严重影响 GC 的性能。

从功能上来说， finalize() 方法与 C++ 中的析构函数比较相似，但是 Java 采用的是基于垃圾回收器的自动内存管理机制，所以 finalize() 方法在本质上不同于 C++ 中的析构函数。

虚拟机中的对象三种状态：

如果从所有的根节点都无法访问到某个对象，说明对象己经不再使用了。一般来说，此对象需要被回收。但事实上，也并非是“非死不可”的，这时候它们暂时处于“缓刑”阶段。一个无法触及的对象有可能在某一个条件下“复活”自己，如果这样，那么对它的回收就是不合理的，为此，定义虚拟机中的对象可能的三种状态。如下：

• 可触及的：从根节点开始，可以到达这个对象。
• 可复活的：对象的所有引用都被释放，但是对象有可能在 finalize() 中复活。
• 不可触及的：对象的 finalize() 被调用，并且没有复活，那么就会进入不可触及状态。不可触及的对象不可能被复活，因为 finalize() 只会被调用一次。

以上3种状态中，是由于 finalize() 方法的存在，进行的区分。只有在对象不可触及时才可以被回收。

finalize() 具体过程：

判定一个对象 objA 是否可回收，至少要经历两次标记过程：

1. 如果对象 objA 到 GC Roots 没有引用链，则进行第一次标记。
2. 进行筛选，判断此对象是否有必要执行 finalize() 方法
3. 如果对象 objA 没有重写 finalize() 方法，或者 finalize()方法已经被虚拟机调用过，则虚拟机视为“没有必要执行”，objA 被判定为不可触及的。
4. 如果对象 objA 重写了 finalize() 方法，且还未执行过，那么 objA 会被插入到 F-Queue
   队列中，由一个虚拟机自动创建的、低优先级的 Finalizer 线程触发其 finalize() 方法执行。
5. finalize() 方法是对象逃脱死亡的最后机会，稍后 GC 会对 F-Queue 队列中的对象进行第二次标记。如果 objA 在finalize() 方法中与引用链上的任何一个对象建立了联系，那么在第二次标记时，objA 会被移出“即将回收”集合。之后，对象会再次出现没有引用存在的情况。在这个情况下， finalize() 方法不会被再次调用，对象会直接变成不可触及的状态，

也就是说，一个对象的 finalize() 方法只会被调用一次。

代码演示

我们使用重写 finalize() 方法，然后在方法的内部，重写将其存放到 GC Roots 中

package com.cy.java;

public class CanReliveObj {
    // 类变量，属于GC Roots的一部分
    public static CanReliveObj canReliveObj;

    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("调用当前类重写的finalize()方法");
        canReliveObj = this;
    }

    public static void main(String[] args) throws InterruptedException {
        canReliveObj = new CanReliveObj();
        canReliveObj = null;
        System.gc();
        System.out.println("-----------------第一次gc操作------------");
        // 因为Finalizer线程的优先级比较低，暂停2秒，以等待它
        Thread.sleep(2000);
        if (canReliveObj == null) {
            System.out.println("obj is dead");
        } else {
            System.out.println("obj is still alive");
        }

        System.out.println("-----------------第二次gc操作------------");
        canReliveObj = null;
        System.gc();
        // 下面代码和上面代码是一样的，但是 canReliveObj却自救失败了
        Thread.sleep(2000);
        if (canReliveObj == null) {
            System.out.println("obj is dead");
        } else {
            System.out.println("obj is still alive");
        }

    }
}

在进行第一次清除的时候，我们会执行 finalize() 方法，然后对象进行了一次自救操作，但是因为 finalize() 方法只会被调用一次，因此第二次该对象将会被垃圾清除。

4. MAT 与 JProfiler 的 GC Roots 溯源

1. MAT 是什么？

• MAT 是Memory Analyzer 的简称，它是一款功能强大的 Java 堆内存分析器。用于查找内存泄漏以及查看内存消耗情况。
• MAT 是基于 Eclipse 开发的，是一款免费的性能分析工具。
• 大家可以在http://www.eclipse.org/mat/下载并使用 MAT
  

2. 获取dump文件

方法一：命令行使用 jmap

方法二：使用 JVisualVM

1. 在左侧“Application"（应用程序）子窗口中右击相应的应用程序，选择Heap Dump（堆Dump）。
2. 在Monitor（监视）子标签页中点击Heap Dump（堆Dump）按钮。本地应用程序的Heap dumps作为应用程序标签页的一个子标签页打开。同时，heap dump在左侧的Application（应用程序）栏中对应一个含有时间戳的节点。
3. 右击这个节点选择save as（另存为）即可将heap dump保存到本地。
   
   

使用 MAT 打开 Dump 文件

打开后，我们就可以看到有哪些可以作为 GC Roots 的对象

3. JProfiler 的 GC Roots 溯源

我们在实际的开发中，一般不会查找全部的 GC Roots，可能只是查找某个对象的整个链路，或者称为 GC Roots溯源，这个时候，我们就可以使用 JProfiler

• 我们通过Show Selection In Heap Walker 来查询char[] 的具体情况：

• 可以通过References中的Incoming references（溯源）来查看从哪个GC Root关联的。
  

如何判断什么原因造成 OOM

当我们程序出现OOM的时候，我们就需要进行排查，我们首先使用下面的例子进行说明

package com.cy.java;

import java.util.ArrayList;

/** -Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError
 1. 内存溢出排查
 2.  */
public class HeapOOM {
    // 创建1M的文件
    byte [] buffer = new byte[1 * 1024 * 1024];

    public static void main(String[] args) {
        ArrayList<HeapOOM> list = new ArrayList<>();
        int count = 0;
        try {
            while (true) {
                list.add(new HeapOOM());
                count++;
            }
        } catch (Exception e) {
            e.getStackTrace();
            System.out.println("count:" + count);
        }
    }
}

1. 上述代码就是不断的创建一个1M小字节数组，然后让内存溢出，我们需要限制一下内存大小，

2. 同时使用-XX:+HeapDumpOnOutOfMemoryError将出错时候的dump文件输出。

-Xms8m -Xmx8m -XX:+HeapDumpOnOutOfMemoryError

• 我们将生成的dump文件打开，然后点击Biggest Objects就能够看到超大对象
  
  然后我们通过线程，还能够定位到哪里出现 OOM