HotSpot的算法细节实现

相信美好的事情即将发生 ᅟᅠ

已于 2024-07-18 08:45:27 修改

阅读量669

点赞数 10

分类专栏： JVM 文章标签：算法 java 数据库开发语言多线程 juc 大数据

于 2024-07-17 14:25:20 首次发布

本文链接：https://blog.csdn.net/weixin_69039908/article/details/140490755

版权

JVM 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

1.根节点枚举

1.1 可达性分析的难度

我们以可达性分析算法中从GC Roots 集合找引用链这个操作作为介绍虚拟机高效实现的第一个例子。固定可作为GC Roots 的节点主要在全局性的引用（例如常量或类静态属性）与执行上下文（例如栈帧中的本地变量表）中，尽管目标明确，但查找过程要做到高效并非一件容易的事情，现在Java应用越做越庞大，光是方法区的大小就常有数百上千兆，里面的类、常量等更是恒河沙数，若要逐个检查以这里为起源的引用肯定得消耗不少时间。

1.2 根节点枚举产生的问题

所有收集器在根节点枚举这一步骤时都是必须暂停用户线程的，因此毫无疑问根节点枚举与之前提及的整理内存碎片一样会面临相似的“Stop The World”的困扰。即使是号称停顿时间可控，或（几乎）不会发生停顿的CMS、G1、 ZGC等收集器，枚举根节点时也是必须要停顿的。

1.3 解决办法

所以当用户线程停顿下来之后，其实并不需要一个不漏地检查完所有执行上下文和全局的引用位置，虚拟机应当是有办法直接得到哪些地方存放着对象引用的。在HotSpot的解决方案里，是使用一组称为OopMap的数据结构来达到这个目的。

一旦类加载动作完成的时候，HotSpot就会把对象内什么偏移量上是什么类型的数据计算出来，在即时编译过程中，也会在特定的位置记录下栈里和寄存器里哪些位置是引用。这样收集器在扫描时就可以直接得知这些信息了，并不需要真正一个不漏地从方法区等GC Roots 开始查找。

2.安全点

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

实际上HotSpot 也的确没有为每条指令都生成 OopMap ，前面已经提到，只是在 “ 特定的位置 ” 记录了这些信息，这些位置被称为安全点（Safepoint ）。

有了安全点的设定，也就决定了用户程序执行时并非在代码指令流的任意位置都能够停顿下来开始垃圾收集，而是强制要求必须执行到达安全点后才能够暂停。因此，安全点的选定既不能太少以至于让收集器等待时间过长，也不能太过频繁以至于过分增大运行时的内存负荷。

安全点位置的选取基本上是以“ 是否具有让程序长时间执行的特征 ” 为标准进行选定的，因为每条指令执行的时间都非常短暂，程序不太可能因为指令流长度太长这样的原因而长时间执行，“ 长时间执行 ” 的最明显特征就是指令序列的复用。

3.如何让所有线程都跑到最近的安全点

3.1 抢先式中断

抢先式中断不需要线程的执行代码主动去配合，在垃圾收集发生时，系统首先把所有用户线程全部中断，如果发现有用户线程中断的地方不在安全点上，就恢复这条线程执行，让它一会再重新中断，直到跑到安全点上。现在几乎没有虚拟机实现采用抢先式中断来暂停线程响应GC事件。

3.2 主动式中断

而主动式中断的思想是当垃圾收集需要中断线程的时候，不直接对线程操作，仅仅简单地设置一个标志位，各个线程执行过程时会不停地主动去轮询这个标志，一旦发现中断标志为真时就自己在最近的安全点上主动中断挂起。轮询标志的地方和安全点是重合的，另外还要加上所有创建对象和其他需要在Java堆上分配内存的地方，这是为了检查是否即将要发生垃圾收集，避免没有足够内存分配新对象。

4.安全区域

安全点的概念，只解决了正在执行的线程的问题。

所谓的程序不执行就是没有分配处理器时间，典型的场景便是用户线程处于Sleep状态或者 Blocked 状态，这时候线程无法响应虚拟机的中断请求，不能再走到安全的地方去中断挂起自己，虚拟机也显然不可能持续等待线程重新被激活分配处理器时间。对于这种情况，就必须引入安全区域（Safe Region ）来解决。

安全区域是指能够确保在某一段代码片段之中，引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。我们也可以把安全区域看作被扩展拉伸了的安全点。

当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，那样当这段时间里虚拟机要发起垃圾收集时就不必去管这些已声明自己在安全区域内的线程了。当线程要离开安全区域时，它要检查虚拟机是否已经完成了根节点枚举（或者垃圾收集过程中其他需要暂停用户线程的阶段），如果完成了，那线程就当作没事发生过，继续执行；否则它就必须一直等待，直到收到可以离开安全区域的信号为止。

5.记忆集与卡表

垃圾收集器在新生代中建立了名为记忆集（Remembered Set）的数据结构，用以避免把整个老年代加进 GC Roots 扫描范围。

记忆集是一种用于记录从非收集区域指向收集区域的指针集合的抽象数据结构。如果我们不考虑效率和成本的话，最简单的实现可以用非收集区域中所有含跨代引用的对象数组来实现这个数据结构。

这种记录全部含跨代引用对象的实现方案，无论是空间占用还是维护成本都相当高昂。而在垃圾收集的场景中，收集器只需要通过记忆集判断出某一块非收集区域是否存在有指向了收集区域的指针就可以了，并不需要了解这些跨代指针的全部细节。那设计者在实现记忆集的时候，便可以选择更为粗犷的记录粒度来节省记忆集的存储和维护成本，下面列举了一些可供选择（当然也可以选择这个范围以外的）的记录精度：

· 字长精度：每个记录精确到一个机器字长（就是处理器的寻址位数，如常见的 32 位或 64 位，这个

精度决定了机器访问物理内存地址的指针长度），该字包含跨代指针。

· 对象精度：每个记录精确到一个对象，该对象里有字段含有跨代指针。

· 卡精度：每个记录精确到一块内存区域，该区域内有对象含有跨代指针。

字节数组CARD_TABLE 的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“ 卡页 ” （ Card Page ）。一般来说，卡页大小都是以 2 的 N 次幂的字节数，通过上面代码可以看出HotSpot 中使用的卡页是 2 的 9 次幂，即 512 字节（地址右移 9 位，相当于用地址除以 512 ）。那如果卡表标识内存区域的起始地址是0x0000 的话，数组 CARD_TABLE 的第 0 、 1 、 2 号元素，分别对应了地址范围为0x0000 ～ 0x01FF 、 0x0200 ～ 0x03FF 、 0x0400 ～ 0x05FF 的卡页内块。

一个卡页的内存中通常包含不止一个对象，只要卡页内有一个（或更多）对象的字段存在着跨代指针，那就将对应卡表的数组元素的值标识为1 ，称为这个元素变脏（ Dirty ），没有则标识为 0 。在垃圾收集发生时，只要筛选出卡表中变脏的元素，就能轻易得出哪些卡页内存块中包含跨代指针，把它们加入GC Roots 中一并扫描。

6.并发的可达性分析（三色标记）

由于GC Roots 相比起整个Java堆中全部的对象毕竟还算是极少数，且在各种优化技巧（如 OopMap ）的加持下，它来的停顿已经是非常短暂且相对固定（不随堆容量而增长）的了。可从GC Roots 再继续往下遍历对象图，这一步骤的停顿时间就必定会与Java 堆容量直接成正比例关系了：堆越大，存储的对象越多，对象图结构越复杂，要标记更多对象而产生的停顿时间自然就更长，这听起来是理所当然的事情。

要知道包含“ 标记 ” 阶段是所有追踪式垃圾收集算法的共同特征，如果这个阶段会随着堆变大而等比例增加停顿时间，其影响就会波及几乎所有的垃圾收集器，同理可知，如果能够削减这部分停顿时间的话，那收益也将会是系统性的。

我们引入三色标记（ Tri-color Marking ） [1] 作为工具来辅助推导，把遍历对象图过程中遇到的对象，按照“ 是否访问过 ” 这个条件标记成以下三种颜色：

· 白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是

白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

· 黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代

表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对

象不可能直接（不经过灰色对象）指向某个白色对象。

· 灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

出现的问题：

一种是把原本消亡的对象错误标记为存活，这不是好事，但其实是可以容忍的，只不过产生了一点逃过本次收集的浮动垃圾而已，下次收集清理掉就好。

另一种是把原本存活的对象错误标记为已消亡，这就是非常致命的后果了，程序肯定会因此发生错误。