JVM--垃圾回收算法

2401_84815783

于 2024-05-16 09:55:43 发布

阅读量268

点赞数 5

分类专栏：程序员文章标签： jvm 算法

本文链接：https://blog.csdn.net/2401_84815783/article/details/138947558

版权

程序员专栏收录该内容

110 篇文章 0 订阅

订阅专栏

基本思路就是通过一系列称为「GC Roots」的根对象作为起始节点对象，从这些节点开始，根据引用关系向下搜索，统计下级，搜索过程所走过的路径称为「引用链」。

如果某个对象到GC Roots间没有任何引用链相连，则证明此对象是不可能再被使用的。

在这里插入图片描述

在Java技术体系里面，固定可作为GC Root的对象包括以下几种：

在虚拟机枝中引用的对象，譬如各个线程被调用的方法堆栈中使用到的参数、局部变量、临时变量等；
在方法区中类静态属性引用的对象，譬如Java类的引用类型静态变量；
在方法区中常量引用的对象，譬如字符串常量池里的引用；
在本地方法栈中引用的对象；
JVM内部的引用，如基本数据类型对应的Class对象，常驻的异常对象（如NullPointExcepition），以及系统类加载器；
所有被同步锁（synchronized关键字）持有的对象；
…

1.2.2 对象的引用级别

无论是通过引用计数算法判断对象的引用数量，还是通过可达性分析算法判断对象是否引用链可达，判定对象是否存活都离不开“引用”。

「强引用、软引用、弱引用、虚引用」这四种引用强度依次逐渐减弱。

强引用：强引用是最传统的“引用”的定义：是指在程序代码之中普遍存在的引用赋值，即类似“Object obj = new Object()” 这种引用关系。无论任何情况下，只要强引用关系还存在，垃圾收集器就永远不会回收掉被引用的对象。
软引用：软引用是用来描述一些还有用，但非必须的对象。只被软引用关联着的对象，在系统将要发生内存溢出异常前，会把这些对象列进回收范围之中进行第二次回收。如果这次回收还没有足够的内存，才会抛出内存溢出异常。
弱引用：弱引用也是用来描述那些非必须的对象，但是它的强度比软引用更弱一些，被弱引用关联的对象只能生存到下一次垃圾收集发生为止。当垃圾收集器开始工作，无论当前内存是否足够，都会回收掉只被弱引用关联的对象。
虚引用：虚引用是最弱的一种引用关系。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用来取得一个对象实例。为一个对象设置虚引用关联的唯一目的只是为了能在这个对象被收集器回收时收到一个系统通知。

1.2.3 对象死亡的过程

「真正宣告一个对象死亡，至少要经历两次标记过程」：

第一次标记：如果对象在进行可达性分析后发现没有与GC Roots相连接的引用链，那它将会被第一次标记，随后进行一次筛选，筛选的条件是此对象是否有必要汍行加「 finzlize() 」方法。

假如对象没有覆盖 finzlize() 方法，或者 finzlize() 方法已经被虚拟机调用过，那么虚拟机将这两种情况都视为“ 没有必要执行 ”。

反之，该对象将会被放置在一个名为「 F-Queue 」的队列之中，并在稍后由一条由虚拟机自动建立的、低调度优先级的如Finzlizer线程去执行它们的finzlize()方法。

第二次标记：稍后，收集器将对 F-Queue 中的对象进行第二次小规模的标记。

如果对象要在finzlize()中成功拯救自己，只要重新与引用链上的任何一个对象建立关联即可。例如把自己（this）赋值给某个类变量或者对象的成员变量，那在第二次标记时它将被移出 “即将回收” 的集合。

如果对象这时候还没有逃脱，那基本上它就真的要被回收了。

Java中Object的finalize()方法

Object 类的 Finalize 方法，可以告诉垃圾回收器应该执行的操作，该方法从 Object 类继承而来。在从堆中永久删除对象之前，垃圾回收器调用该对象的 Finalize 方法。

注意，无法确切地保证垃圾回收器何时调用该方法，也无法保证调用不同对象的方法的顺序。即使一个对象包含另一个对象的引用，或者在释放一个对象很久以前就释放了另一个对象，也可能会以任意的顺序调用这两个对象的Finalize方法。如果必须保证采用特定的顺序，则必须提供自己的特有清理方法。

finalize() 方法是对象逃脱死亡命运的最后一次机会，需要注意的是，任何一个对象的finalize() 方法都只会被系统自动调用一次，如果对象面临下一次回收，它的finalize()方法不会被再次执行。另外，finalize()方法运行代价高昂，不确定性大，无法保证各个对象的调用顺序，不推荐使用的语法。

1.3 回收方法区

方法区的垃圾收集主要回收两部分内容：「 废弃的常量 」和「 不再使用的类型 」。

1.3.1 回收废弃的常量

假如一个字符串“Java”曾经进入常量池中，但是当前系统又没有任何一个字符串对象的值是“Java”。

换句话说，已经没有任何字符串对象引用常量池中的“Java”常量，且虚拟机中也没有其他地方引用这个字面量。如果在这时发生内存回收，而且垃圾收集器判断确有必要的话，这个“Java”常量就将会被系统清理出常量池。

常量池中其他类（接口）、方法、字段的符号引用也与此类似。

1.3.2 回收不使用的类

要判定一个类型是否属于「不再被使用的类」。需要同时满足下面三个条件：

该类所有的实例都已经被回收，也就是堆中不存在该类及其任何派生子类的实例；
加载该类的类加载器已经被回收，这个条件除非是经过精心设计，一般是很难达成的;
该类对应的 java.lang.Class 对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。

Java虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。关于是否要对类型进行回收，HotSpot虚拟机提供了-Xnoclassgc参数进行控制。

1.4 垃圾回收算法

1.4.1 分代收集理论

当前商业虚拟机的垃圾收集器，大多数都遵循了“分代收集”的理论进行设计，分代收集理论，实

质是一套符合大多数程序运行实际情况的经验法则。而分代收集理论，建立在如下「三个分代假说」之上：

**1. 「弱分代假说」：绝大多数对象都是朝生夕灭的。

2. 「强分代假说」：熬过越多次垃圾收集过程的对象越难以消亡。

3. 「跨代引用假说」：跨代引用相对于同代引用来说只占极少数。**

前两条假说共同奠定了多款常用的垃圾收集器的一致设计原则：收集器应该将 Java堆划分出不同的内存区域，然后将回收对象依据其「年龄」（年龄即对象熬过垃圾收集过程的次数）分配到不同的区域中存储。

显而易见，如果一个区域的大多数对象都朝生夕死，难以熬过垃圾收集过程的话，那么把它们集中在一起，每次垃圾收集的时候只关注如何保留少量的存活，而不是去标记那些大量将要被回收的对象，就能以极低的代价回收大量空间。

如果剩下的都是难以消亡的对象，把它们集中放在一块，虚拟机可以以极低的频率来回收这个区域，这就能用时兼顾了垃圾收集的时间开销和内存空间的有效利用。

设计者一般至少把Java堆划分为「新生代（Young Generation）」和「老年代（Old Generation）」两个区域。

顾名思义，在新生代中，每次垃圾收集时都会发现大批的对象死去，而每次回收后的存活的少量对象，将会逐步晋升到老年代中存放。

大多数虚拟机，如HotSpot而言，虚拟机原码中包含一些名为「*Generation」的实现，如DefNewGeneration 和 ParNewGeneration 等分代式垃圾收集框架。原本HotSpot是鼓励开发者在这个框架内开发新的垃圾收集器，但是除了最早期的两组四款收集器外，后来开发者并没有遵循这个框架。导致此事的原因很多，最根本原因是分代的垃圾收集理论仍在不断发展之中，如何实现也有很多细节可以改进，被既定的框架约数反而不便。

其实，思考一下，就容易发现出分代的垃圾收并非简单的划分一下内存区域那么简单，它至少存在一个困难：「对象不是孤立的，对象之间会存在跨代引用」。

假如要进行一次局限于新生代区域的内存收集（Minor GC），但新生代对象完全可能会被老年代引用，为了找到该区域的存活对象，不得不在固定的GC Roots之外，在遍历整个老年代中所有对象确保可达性分析的正确性，反之也是一样。遍历整个老年代理论上可行，但无疑会给内存回收带来负担。为了解决这个问题，就需要堆分代收集理论添加第三条经验法则。

第三条假说是根据前面两条假说逻辑推理出的隐含推论：「存在相互引用关系的两个对象应该倾向于同时生存和死亡」。

例如：如果某个新生代对象存在跨年代引用，由于老年代难以消亡，那么该引用使得新生代对象在垃圾收集时得以生存，进而在年龄上增加，长久之后就会晋升到老年代，那么跨年代引用就消除了。

依据这条假说，我们就不应该再为少量的跨年代引用而去扫描整个老年代，也不必浪费空间去专门记录每一个对象是否存在及存在那些跨年代引用，只需在新生代上建立一个全局的数据结构。该结构被称为「“记忆集”， Remembered Set」，这个结构会把老年代划分成若干个小块，标识出老年代那个块内存存在跨年代引用。

此后，当发生Minor GC的时，只有包含跨代引用的小块内存里的对象才会被加入到GC Roots里进行扫描。虽然这种方法需要在对象改变引用关系（如将自己或某个属性进行赋值）时维护数据的正确性，会增加一些运行时的开销，但比起扫描整个老年代还是划算的。

依据分代假说理论，垃圾回收可以分为如下几类：

新生代收集（Minor GC/Young GC）：目标为新生代的垃圾收集。
老年代收集（Major GC/Old GC）：目标为老年代的垃圾收集，目前只有CMS收集器会有这种行为。
混合收集（Mixed GC）：目标为整个新生代及部分老年代的垃圾收集，目前只有G1收集器会有这种行为。
整堆收集（Full GC）：目标为整个堆和方法区的垃圾收集。

1.4.2 标记清除算法

算法分为「标记」和「清除」两个阶段：首先标记出所需要回收的对象，在标记完成后统一回收掉所有被标记的对象，也可以反过来，标记存活的对象，统一回收掉未被标记的对象。

它的主要缺点有两个：

第一个是「执行效率不太稳定」，如果Java堆中包含大量的对象，其中大部分是要被回收的，这是必须要进行大量的标记与清除动作，导致标记和清除两个过程的执行效率都随对象数量的增长而降低。
第二个是「内存空间碎片化的问题」，标记、清除后会产生大量的不连续的内存碎片，空间碎片太多会导致当以后程序运行过程中需要分配较大的对象无法找到足够的连续内存而不得不提前触发另一次垃圾收集。

在这里插入图片描述

1.4.3 标记复制算法

标记-复制算法常被称之为「复制算法」。

为解决标记-清除算法面对大量可回收对象时执行效率低下的问题1969年提出了一种称为「半区复制」（Semispace Copying）的垃圾收集算法。它将内存按容量划分成大小相等的两块，每次只使用其中一块。当一块（A块）用完了，它将（A块）还存活的对象复制到另一块（B块）内存上，然后把（A块）已使用过的内存空间一次清除掉。

如果内存中多数对象都是存活的，这种算法将产生大量的内存键复制开销，但对于多数对象都是可回收的情况，该算法就只需复制占少数的存活对象，而且每次只针对半区进行内存回收，分配对象时也不需要考虑空间碎片的复杂性，只要移动堆顶指针，按顺序分配即可。

在这里插入图片描述

现在商用的Java虚拟机大都采用了这种收集算法去回收新生代，IBM公司曾有一项研究显示：新生代中对象有98%熬不过第一轮回收。因此不需要按照1:1的比例来划分新生代内存空间。1989年，提出了一种更优化的半区复制分代策略，现在称为「Appel式回收」。

Appel式回收的具体做法是把新生代划分成「一块较大的Eden空间」和「两块较小的Survivor空间」，「每次分配内存只是用Eden和其中一块Survivor区域」。发生垃圾收集时，把Eden和Survivor中仍然存活的对象一次性复制到另一块Survivor空间上，然后直接清除掉Eden和已使用过的那块Survivor空间。

HotSpot虚拟机的默认Eden和Survivor大小比例是「8:1」，也即每次新生代可用内存为整个新生代空间内存的90%（Eden的80%和一块Survivor的10%），只有一个Survivor空间，即10%会被浪费掉。当Survivor的内存不足以容纳一次Minor GC后存活的对象时，就需要依赖其他内存区域（实际上大多是老年代）进行分配担保（Handle Promotion）。