JVM 判断对象是否存活、垃圾收集算法、HotSpot的算法细节

CodingAnHour

已于 2022-09-25 11:16:15 修改

阅读量663

点赞数

分类专栏： JVM 文章标签： jvm 算法 java

于 2022-04-21 01:05:41 首次发布

本文链接：https://blog.csdn.net/Extraordinarylife/article/details/124309502

版权

JVM 专栏收录该内容

8 篇文章 2 订阅

订阅专栏

垃圾收集器（Garbage Collection，简称GC）

Java内存运行时区域中程序计数器、虚拟机栈、本地方法栈3个区域随着线程而生，岁线程而灭，栈中的栈帧随着方法的进去与退出而有条不絮地执行着出栈和入栈每个栈帧中分配多少内存基本上在编译期可知的；

Java堆和方法区这两个域有着显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需的内存可能不一样，只有处于运行期间，才知道程序究竟会创建那些对象，创建多少个对象，这部分的内存分配与创建是动态的，垃圾收集器所关注的就是这部分内存的创建与回收

年轻代中，对应常规应用一次垃圾回收通常可以回收70%~90%的内存空间

1、判断对象是否存活

垃圾收集器回收前第一件事就是要确定对象中那些还“活着”，那些“已死（不可能在被任何途径使用的对象）”

1.1、引用计数算法

在对象中添加一个引用计数器，每当一个地方引用就加一，引用失效就减一，引用为零时表示对象不可能再被使用的，原理简单，高效。无法解决对象之间循环引用的问题，Java 使用的不是引用计数算法来进行标记的

/**
* -XX:+PrintGCDetails
* 证明：java 使用的不是引用计数算法
*/
public class RefCountGC {
    // 这个成员属性唯一的作用就是占用一点内存
    private byte[] bigSize = new byte[5 * 1024 * 1024]; // 5MB
 
    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();
}

1.2、可达性分析算法

当前主流的商用程序语言(Java、C#)的内存管理子系统，都是通过可达性分析(Reachability Analysis) 算法来判定对象是否存活的。

算法得基本思路就是通过一系列称为 “GC Roots” 的跟对象作为起始节点集，根据引用关系像下搜索，搜索过程所走过的路径成为 “引用链”(Reference Chain)，如果某个对象到 GC Roots 间没有任何引用链相连，或者用图论的话来说就是从 GC Roots 到这个对象不可达，则证明此对象是不可能再被使用的。
在这里插入图片描述
Java技术体系中，可作为GC Roots的对象包括以下几种：

在虚拟机栈（栈帧中的本地变量表）中引用的对象。例如：各个线程被调用的方法堆栈中使用到的参数，局部变量，临时变量等
方法区中类静态属性引用的对象。例如：Java类的引用类型静态变量
方法区中常量引用的对象。例如：字符串常量池（String Table）中的引用
本地方法栈中JNI(即一般说的Native方法)引用的对象
Java虚拟机内部的引用，如基本数据类型对应的Class 对象，一些常驻的异常对象(NullPointExeception、OutOfMemoryError等)，还有系统类加载器
所有被同步锁(Synchronized)持有的对象
反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回调、本地代码缓存等

1.13、常见引用类型

当内存足够时，能保留在内存中；内存空间在进行垃圾回收后仍然非常紧张，那么就可以抛弃这些对象

java的引用类型一般分为四种：强引用、软引用、弱引用、虚引用

强引用：普通的变量引用

public static User user = new User();
软引用：将对象用SoftReference软引用类型的对象包裹，正常情况不会被回收，但是GC做完后发现释放不出空间存放新的对象，则会把这些软引用的对象回收掉。软引用可用来实现内存敏感的高速缓存。

public static SoftReference user = new SoftReference(new User());

软引用在实际中有重要的应用，例如浏览器的后退按钮。按后退时，这个后退时显示的网页内容是重新进行请求还是从缓存中取出呢？这就要看具体的实现策略了。
- 如果一个网页在浏览结束时就进行内容的回收，则按后退查看前面浏览过的页面时，需要重新构建
- 如果将浏览过的网页存储到内存中会造成内存的大量浪费，甚至会造成内存溢出
弱引用：将对象用WeakReference软引用类型的对象包裹，弱引用跟没引用差不多，GC会直接回收掉，很少用

public static WeakReference user = new WeakReference(new User());
虚引用：虚引用也称为幽灵引用或者幻影引用，它是最弱的一种引用关系，几乎不用

1.1.4、终判定对象是否存活

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

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

第一次标记并进行一次筛选。
筛选的条件是此对象是否有必要执行finalize()方法。
当对象没有覆盖finalize方法，对象将直接被回收。
第二次标记
如果这个对象覆盖了finalize方法，finalize方法是对象脱逃死亡命运的最后一次机会，如果对象要在finalize()中成功拯救自己，只要重新与引用链上的任何的一个对象建立关联即可，譬如把自己赋值给某个类变量或对象的成员变量，那在第二次标记时它将移除出“即将回收”的集合。如果对象这时候还没逃脱，那基本上它就真的被回收了。
注意：一个对象的finalize()方法只会被执行一次，也就是说通过调用finalize方法自我救命的机会就一次。

public class OOMTest {

   public static void main(String[] args) {
      List<Object> list = new ArrayList<>();
      int i = 0;
      int j = 0;
      while (true) {
         list.add(new User(i++, UUID.randomUUID().toString()));
         new User(j--, UUID.randomUUID().toString());
      }
   }
}


//User类需要重写finalize方法
@Override
protected void finalize() throws Throwable {
    OOMTest.list.add(this);
    System.out.println("关闭资源，userid=" + id + "即将被回收");
}

finalize()方法的运行代价高昂，不确定性大，无法保证各个对象的调用顺序，如今已被官方明确声明为不推荐使用的语法。有些资料描述它适合做“关闭外部资源”之类的清理性工作，这完全是对finalize()方法用途的一种自我安慰。 finalize()能做的所有工作，使用try-finally或者其他方式都可以做得更好、更及时，所以建议大家完全可以忘掉Java语言里面的这个方法。

1.15、类与常量的回收

方法区的垃圾收集主要包含2部分：废弃的常量和不再使用的类型。

废弃常量：回收废弃常量与回收Java堆中的对象非常类似

以常量池中字面量的回收为例：假如一个字符串“abc”已经进入常量池中，但是当前系统没有任何一个String对象引用常量池中的“abc”常量，也没有其他地方引用这个字面量，如果这时发生内存回收，而且必要的话，这个“abc”常量就会被系统清理出常量池。常量池中的其他类（接口）、方法、字段的符号引用也与此类似

判断一个类是“无用的类”需要满足3个条件：

该类所有的实例都已经被回收，也就是Java堆中不存在该类的任何实例
加载该类的ClassLoader已经被回收
该类对应的java.lang.Class 对象没有在任何地方被使用，无法在任何地方通过反射访问该类的方法。

虚拟机可以对满足以上3个条件的无用类进行回收，这里说的仅仅是“可以”，而不是和对象一样，不使用了就必然会被回收。

2、垃圾收集算法

2.1、分代收集理论

当前虚拟机的垃圾收集都采用分代收集算法，根据对象存活周期的不同将内存分为几块。一般将java堆分为新生代和老年代，这样我们就可以根据各个年代的特点选择合适的垃圾收集算法。
比如在新生代中，每次收集都会有大量对象(近99%)死去，所以可以选择复制算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

2.2、标记-复制算法

为了解决效率问题，“复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收。
在这里插入图片描述

2.3、标记-清除算法

算法分为“标记”和“清除”阶段：标记存活的对象，统一回收所有未被标记的对象(一般选择这种)；也可以反过来，标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象。它是最基础的收集算法，比较简单，但是会带来两个明显的问题：

效率问题 (如果需要标记的对象太多，效率不高)
空间问题（标记清除后会产生大量不连续的碎片）

2.4、标记-整理算法

根据老年代的特点特出的一种标记算法，标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存。

这种对象移动操作必须全程暂停用户应用程序（用户线程）才能进行称为“Stop The World”（STW）
在这里插入图片描述

3、HotSpot的算法细节

3.1、根节点枚举

以可达性分析中从GC Roots 节点找引用链这个操作为例，可作为GC Roots 的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，现在的很多应用仅仅方法区就有数百兆，如果要逐个检查这里面的引用，那么必然会消耗很多时间。

另外，可达性分析对执行时间的敏感还体现在GC停顿上（STW），因为这项分析工作必须在一个能确保一致性的快照中进行（一致性的意思是指在整个分析期间，分析过程中需要保证对象引用关系是不变的，该点不满足的话分析结果的准确性就无法得到保证）。这点导致GC进行时必须停顿所有Java执行线程（Stop The World）的其中一个重要的原因，即使在号称（几乎）不会发生停顿的CMS、G1、ZGC收集器中，枚举根节点时也是必须要停顿的。

目前主流的Java虚拟机使用的都是准确式GC，所以当执行系统停顿下来后，并不需要一个不漏的检查完所有的执行上下文和全局的引用位置，虚拟机应当是有办法直接得知哪些地方存在着对象引用。在HotSpot的实现中，是使用一组称为OopMap的数据结构来达到这个目的的，在类加载完成的时候，HotSpot就把对象内什么偏移量上是什么类型的数据计算出来，在JIT编译过程中，也会在特定的位置记录下栈和寄存器中哪些位置是引用。这样，GC在扫描时就可以直接得知这些信息了。

3.2、安全点

在OopMap的协助下，HotSpot可以快速且准确地完成GC Roots枚举，但一个很现实的问题随之而来：可能导致引用关系变化，或者说OopMap内容变化的指令非常多，如果为每一条指令都生成对应的OopMap，那将会需要大量的额外空间，这样GC的空间成本将会变得很高。

实际上，HotSpot也的确没有为每条指令都生成OopMap，前面已经提到，只是在“特定的位置”记录了这些信息，这些位置称为安全点（Safepoint），即程序执行时并非在所有地方都能停顿下来开始GC，只有在到达安全点时才能暂停。Safepoint的选定即不能太少以至于让GC等待时间太长，也不能过于频繁以至于过分增大运行时负荷。所以，安全点的选定基本上是以程序“是否具有让程序长时间执行的特征”为标准进行选定的–因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这个原因而过长时间运行，“长时间执行”的最明显特征就是指令序列复用，例如方法调用、循环跳转、异常跳转等，所以具有这些功能的指令才会产生Safepoint。

对于Safepoint，另一个需要考虑的问题是如何在GC发生时让所以线程（这里不包括执行JNI调用的线程）都“跑”到最近的安全点上再停顿下来。这里有两种方案可供选择：

抢先式中断（Preemptive Suspension）
主动式中断（Voluntary Suspension）

其中抢先式中断不需要线程的执行代码主动去配合，在GC发生时，首先把所有线程全部中断，如果发现有线程中断的地方不在安全点上，就恢复线程，让它“跑”到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程从而响应GC事件。

而主动式中断的思想是当GC需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志，各个线程执行时主动去轮询这个标志，发现中断标志为真时就自己中断挂起。轮询标志的地方和安全点是重合的，另外再加上创建对象需要分配内存的地方。

3.3、安全区域

使用Safepoint似乎已经完美地解决了如何进入GC的问题，但实际情况却并不一定。Safepoint机制保证了程序执行时，在不太长的时间内就会遇到可进入GC的Safepoint。但是，程序就”不执行“的时候呢？所谓的程序不执行就是没有分配CPU时间，典型的例子就是线程处于Sleep状态或者Blocked状态，这时候线程无法响应JVM的中断请求，”走“到安全的地方去中断挂起，JVM也显然不太可能等待线程重新被分配CPU时间。对于这种情况，就需要安全区域（Safe Region）来解决。

安全区域是指在一段代码片段之中，引用关系不会发生变化。在这个区域中的任意地方开始GC都是安全的。我们也可以把Safe Region看做是被扩展了的Safepoint。

在线程执行到Safe Region中的代码时，首先标识自己已经进入了Safe Region，那样，当在这段时间里JVM要发起GC时，就不用管标识自己为Safe Region状态的线程了。在线程要离开Safe Region时，它要检查系统是否已经完成了根节点枚举（或者是整个GC过程），如果完成了，那线程就继续执行，否则它就必须继续等待直到收到可以安全离开Safe Region的信号为止。

3.4、记忆集与卡表

在新生代做GCRoots可达性扫描过程中可能会碰到跨代引用的对象，这种如果又去对老年代再去扫描效率太低了。

为此，在新生代可以引入记录集（Remember Set）的数据结构（记录从非收集区到收集区的指针集合），避免把整个老年代加入GCRoots扫描范围。事实上并不只是新生代、老年代之间才有跨代引用的问题，所有涉及部分区域收集（Partial GC）行为的垃圾收集器，典型的如G1、 ZGC和Shenandoah收集器，都会面临相同的问题。

垃圾收集场景中，收集器只需通过记忆集判断出某一块非收集区域是否存在指向收集区域的指针即可，无需了解跨代引用指针的全部细节。

hotspot使用一种叫做“卡表”(Cardtable)的方式实现记忆集，也是目前最常用的一种方式。关于卡表与记忆集的关系，可以类比为Java语言中HashMap与Map的关系。

卡表是使用一个字节数组实现：CARD_TABLE[ ]，每个元素对应着其标识的内存区域一块特定大小的内存块，称为“卡页”。
hotSpot使用的卡页是2^9大小，即512字节

在这里插入图片描述

一个卡页中可包含多个对象，只要有一个对象的字段存在跨代指针，其对应的卡表的元素标识就变成1，表示该元素变脏，否则为0.

GC时，只要筛选本收集区的卡表中变脏的元素加入GCRoots里。

卡表的维护：卡表变脏上面已经说了，但是需要知道如何让卡表变脏，即发生引用字段赋值时，如何更新卡表对应的标识为1。Hotspot使用写屏障维护卡表状态。

3.5、写屏障

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理（可以参考AOP的概念）：

void oop_field_store(oop* field, oop new_value) {  
    pre_write_barrier(field);          // 写屏障-写前操作
    *field = new_value; 
    post_write_barrier(field, value);  // 写屏障-写后操作
}

3.6、读屏障

读屏障是直接针对第一步：D d = a.b.d，当读取成员变量时，一律记录下来：

void pre_load_barrier(oop* field) {  
    oop old_value = *field;
    remark_set.add(old_value); // 记录读取到的对象
}

3.7、并发可达性分析（三色标记）

在并发标记的过程中，因为标记期间应用线程还在继续跑，对象间的引用可能发生变化，多标和漏标的情况就有可能发生。

这里我们引入“三色标记”来给大家解释下，把GC Roots可达性分析遍历对象过程中遇到的对象，按照“是否访问过”这个条件标记成以下三种颜色：

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

在这里插入图片描述

Wilson于1994年在理论上证明了，当且仅当以下两个条件同时满足时，会产生“对象消失”的问题，即原本应该是黑色的对象被误标为白色：

赋值器插入了一条或多条从黑色对象到白色对象的新引用；
赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。

我们要解决并发扫描时的对象消失问题，只需破坏这两个条件的任意一个即可。由此分别产生了两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning， SATB）。

第一种方法是增量更新，是破坏第一个条件“插入了一条或多条从黑色对象到白色对象的引用”，当有黑色对象指向白色对象时，就把该黑色对象变成灰色对象，回头再重新扫描一次，这样就可以保证指向的白色对象一定会扫描到。

写屏障实现增量更新
当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D记录下来：
```
// 写屏障后调用
void post_write_barrier(oop* field, oop new_value) {  
    remark_set.add(new_value);  // 记录新引用的对象
}
```

第二种方法是原始快照，是破坏第二个条件“删除了全部从灰色对象到该白色对象的直接或间接引用”，如果要删除灰色对象到白色对象的直接或间接引用时，把这个引用记录下来，回头再以这个记录的引用关系中的灰色对象为根，重新扫描一次。可以理解为虽然这个引用记录删除了，但是还是按原先的引用关系进行扫描。

写屏障实现SATB
当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将B原来成员变量的引用对象D记录下来：

// 写屏障前调用
void pre_write_barrier(oop* field) {
    oop old_value = *field;    // 获取旧值
    remark_set.add(old_value); // 记录原来的引用对象
}

CMS：写屏障 + 增量更新
G1，Shenandoah：写屏障 + SATB
ZGC：读屏障

多标-浮动垃圾

在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

CodingAnHour

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
JVM 判断对象是否存活、垃圾收集算法、HotSpot的算法细节

垃圾收集器（Garbage Collection，简称GC）Java内存运行时区域中程序计数器、虚拟机栈、本地方法栈3个区域随着线程而生，岁线程而灭，栈中的栈帧随着方法的进去与退出而有条不絮地执行着出栈和入栈每个栈帧中分配多少内存基本上在编译期可知的；Java堆和方法区这两个域有着显著的不确定性：一个接口的多个实现类需要的内存可能会不一样，一个方法所执行的不同条件分支所需的内存可能不一样，只有处于运行期间，才知道程序究竟会创建那些对象，创建多少个对象，这部分的内存分配与创建是动态的，垃圾收集器所关注的就
复制链接

扫一扫

专栏目录