8、垃圾回收算法

八、垃圾回收算法

垃圾标记阶段：对象存活判断

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

那么JVM究竟是如何标记一个死亡对象呢?简单类锁，当一个对象已近不再被任何的存活对象继续引用时，就可以宣判为已经死亡。

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

垃圾标记阶段算法——引用计数算法

引用计数算法(Reference Counting)比较简单，对每个对象保存一个整型的引用计数器属性，用于记录对象被引用的情况。

对于一个对象A，只要有任何一个对爱那个引用了A，则A的引用计数器就加1；当引用失效时，引用计数器就减1。只要对象的引用计数器的值为0，即表示对象A不可能再被使用，可进行回收。

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

缺点：

​ 它需要单独的字段存储计数器，这样的做法增加了存储空间的开销。

​ 每次赋值都需要更新计数器，伴随着加法和减法操作，这增加了时间开销。

​ 引用计数器有一个严重的问题，即无法处理循环引用的情况。这是一条致命缺陷，导致在Java的垃圾回收器中没有使用这类算法。

垃圾标记阶段算法——可达性分析算法

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

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

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

基本思路

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

GC Roots

在Java语言中，GC Roots包括以下几类元素：

  • 虚拟机栈中引用的对象
    • 比如：各个线程被调用的方法中使用到的参数、局部变量等。
  • 本地方法栈内JNI(本地方法)引用的对象
  • 方法区中类静态属性引用的对象
    • 比如Java类的引用类型静态变量
  • 方法区中常量引用的对象
    • 比如：字符串常量池(String Table)里的引用
  • 所有被同步锁synchronized持有的对象
  • Java虚拟机内部的引用。
    • 基本数据类型对应的Class对象，一些常驻的异常对象(NullPointerException、OutOfMemoryError)，系统类加载器。
  • 反映Java虚拟机内部情况的JMXBean、JVMTI中注册的回到、本地代码缓存等。
  • 除了这些固定的GC Roots集合外，根据用户所选用的垃圾收集器以及当前回收的内存区域不同，还可以有其他对象“临时性”地加入，共同构成完整GC Roots集合。比如：分代收集和局部回收(Partial GC)。

注意点

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

这点也是导致GC进行时必须“Stop The World”的一个重要原因。

​ 即使是号称(几乎)不会发生停顿的CMS收集器中，枚举根节点时也是必须要停顿的

对象的finalization机制

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

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

finalize()方法允许在子类中被重写，用于在对象被回收时进行资源释放。通常这个方法中进行一些资源释放和清理的工作，比如关闭文件、套接字和数据库连接等。

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

  • 在finalize()时可能会导致对象复活
  • finalize()方法的执行时间是没有保障的，它完全有GC线程决定，极端情况下，若不发生GC，则finalize()方法将没有执行机会
  • 一个糟糕的finalize()会严重影响GC的性能。

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

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

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

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

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

1、如果对象objA到GC Roots没有引用链，则进行第一次标记

2、进行筛选，判断此对象是否有必要执行finalize()方法

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

垃圾清除阶段

当成功区分出内存中存活对象和死亡对象后，GC接下来的任务就是执行垃圾回收，释放掉吴用对象所占用的内存空间，以便有足够的可用该内存空间为新对象分配内存。

目前在JVM中比较常见的三种垃圾收集算法是标记-清除算法(Mark-Sweap)、复制算法(Copying)、标记-压缩算法(Mark-Compact)

标记清除(Mark-Sweep)算法

背景：

标记-清除算法(Mark-Sweep)是一种分厂基础和常见的垃圾收集算法，该算法被J.McCarthy等人在1960年提出并应用与Lisp语言。

执行过程：

当堆中的有效内存空间(available memory)被耗尽的时候，就会停止整个程序(也被称为stop the world)，然后进行两项工作，第一项则是标记，第二项就是清除。

  • 标记：Collector从引用根节点开始遍历，标记所有被引用的对象。一般是在对象的Header中记录为可达对象。
  • 清除：Collector对堆内存从头到尾进行线性的遍历，如果发现某个对象在其Header中没有标记为可达对象，则将其回收。

缺点

  • 效率不算高
  • 在进行GC的时候，需要停止整个引用程序，导致用户体验差
  • 这种方式清理出来的空闲内存是不连续的，产生内存碎片。需要维护一个空闲列表

注意：何为清除？

所谓的清除并不是真的置空，而是把需要清除的独享地址保存在空闲的地址列表里。下次有新对象需要加载时，判断垃圾的位置空间是否够，如果够，就存放。

复制(Copying)算法

背景

为了解决标记-清除算法在垃圾收集效率方面的缺陷，M.LMinsky于1963年发表了著名的论文，“使用双存储区的Lisp语言垃圾收集器CA LISP Garbage Collector Algorithm Using Serial Secondary Storage”。M.L.Minsky在该论文中描述的算法被人们称为复制(Copying)算法，它也被M.L.Minsky本人成功地引入到了Lisp语言的一个实现版本中。

核心思想

将活着的内存空间氛围两块，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对对象复制到未被使用的内存块中，之后清除正在使用的内存块中的所有对象，交换两个内存的角色，最后完成垃圾回收。

优点：

  • 没有标记和清除过程，实现简单，运行高效
  • 复制过去以后保证空间的连续性，不会出现“碎片”问题

缺点：

  • 此算法的缺点也很明显，就是需要两倍的内存空间
  • 对于G1这种分拆称为大量的region的GC，赋值而不是移动，意味着GC需要维护region之间对象引用关系，不管是内存占用或者时间开销也不小。

特别的：

如果系统中的垃圾对象很多，赋值算法需要复制的存活对象数量并不会太大，或者说非常低才行。

应用场景：

在新生代，对常规应用的垃圾回收，一次通常可以回收70%-99%的内存空间。回收性价比很高。所以现在的商业虚拟机都是用这种手机算法回收新生代。

标记-压缩(标记- 整理,Mark-Compact)算法

背景：

复制算法的高效性时间里在存活对象少、垃圾对象多的前提下的。这种情况在新生代经常发生，但是在老年代，更常见的情况是大部分对象都是存活对象。如果依然使用赋值算法，由于存活对象较多，赋值的成本也将很高。因此，基于老年代垃圾回收的特性，需要使用其他的算法。

标记清除算法的确可以应用在老年代，但是该算法不仅执行效率低下，而且在执行完内存回收后还会产生内存碎片，所以JVM的设计者需要在此基础上进行改进。标记-压缩(Mark-Compact)算法由此诞生。

执行过程

第一阶段和标记清除算法一样，从根节点开始标记所有被引用对象。

第二阶段将所有的存活对象压缩到内存的一段，按顺序摆放，之后，清理边界外所有的空间

标记-压缩算法的最终效果等同于标记-清除算法执行完成后，在进行一次内存碎片整理，因此，也可以把它称为标记-清除-压缩(Mark-Sweep-Compact)算法。

二者的本质差异在于标记-清除算法是一种非移动式的回收算法，标记-压缩是移动式的，是否移动回收后的存活对象是一项优缺点并存的风险决策。

可以看到，标记的存活对象将会被整理，按照内存地址依次排列，而未被标记的内存会被清理掉。如此一来，当我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可，这比维护一个空闲列表显然少了许多开销。

优点：

消除了标记-清除算法当中，内存区域分散的缺点，我们需要给新对象分配内存时，JVM只需要持有一个内存的起始地址即可。

消除了复制算法当中，内存减半的高额代价。

缺点：

从效率上来说，标记-整理算法要低于复制算法。

移动对象的同时，如果对象被其他对象引用，则还需要调整引用的地址。

移动过程中，需要全程暂停用户引用程序。即：STW

三种算法的对比

效率上来说，复制算法是当之无愧的老大，但是要浪费很多内存。

而为了尽量兼顾上面提到的三个指标，标记-整理算法相对于来说更平滑些，但是效率上不尽如意，它比复制算法多了一个标记的阶段，比标记-清除多了一个整理内存的阶段。

难道没有一种最优的算法吗？

没有，没有最好的算法， 只有最合适的算法。

分代收集算法

前面所有这些算法中，并没有一种算法可以完全替代其他算法，它们都具有自己独特的优势和特点。分代收集算法应运而生。

分代收集算法，是基于这样一个事实的：不同的对象生命周期是不一样的。因此，不同生命周期的对象可以采取不同的收集方式，以便提高回收效率。一般是把Java堆分为新生代和老年代，这样就可以根据各个年代的特点使用不同的回收算法，以提高垃圾回收的效率。

在Java程序运行的过程中，会产生大量的对象，其中有些对象是与业务信息相关，比如Http请求中的Session对象、线程、Socket连接，这类对象跟业务直接挂钩，因此生命周期较长。但是还有一些对象，主要是程序运行过程中生成的临时变量，这些对象生命周期会比较短，比如：String对象，由于其不变类的特性，系统会产生大量的这些对象，有些对象甚至只用一次即可回收。

目前几乎所有的GC都是采用分代收集(Generational Collecting)算法执行垃圾回收的。

在HotSpot中，基于分代的概念，GC所使用的内存回收算法必须结合年轻代和老年代各自的特点。

  • 年轻代(Young Gen)

    年轻代的特点：区域相对老年代较小，对象生命周期短、存活率低、回收频繁。

    这种情况赋值算法的回收整理，速度是最快的。复制算法的效率只和当前存活对象大小有关，因此很适用于年轻代的回收。而复制算法内存利用率不高的问题，通过HotSpot中的两个survivor的设计得到缓解。

  • 老年代(Tenured Gen)

    老年代的特点：区域较大，对象生命周期长、存活率高，回收不及年轻代频繁。

    这种情况存在大量存活率高的对象，赋值刷反明显变得不合适。一般是由标记-清除或者是标记-清除与标记-整理的混合实现。

    • Mark阶段的开销与存货对象的数量成正比
    • Sweep阶段的开销与所管理区域的大小成正相关
    • Compact阶段的开销与存活对象的数据成正比。

以HotSpot中的CMS回收器为例，CMS是基于Mark-Sweep实现的，对于对象的回收效率很高。而对于碎片问题，CMS采用基于Mark-Compact算法的Serial Old回收器作为补偿措施：当内存回收不佳(碎片导致的Concurrent Mode Failure时)，将采用Serial Old执行Full GC以达到对老年代内存的整理。

分代思想被现有的虚拟机广泛使用。几乎所有的垃圾回收器都区分新生代和老年代。

增量收集算法与分区算法

增量收集算法

上述现有的算法，在垃圾回收过程中，应用软件将处于Stop The World的状态。在Stop the World状态下，所有的线程都会挂起，暂停一切正常的工作，等待垃圾回收的完成。如果垃圾回收时间过长，应用程序会被挂起很久，将严重影响用户体验或者系统的稳定性。为了解决这个问题，即对实时垃圾收集算法的研究直接导致了增量手机(Incremental Collecting)算法的诞生。

基本思想

过一次性将所有的垃圾进行处理，需要造成系统长时间的停顿，那么就可以让垃圾收集线程和应用程序交替执行。每次，垃圾收集线程只收集一小片区域的内存空间，接着切换到应用程序线程。依次反复，直到垃圾收集完成。

总的来说，增量手机算法的基础仍然是传统的标记-清除和赋值算法。增量收集算法通过对线程冲突的妥善处理，允许垃圾收集线程以分阶段的方式来完成标记、清理或复制工作。

缺点：

使用这种方式，由于在垃圾回收过程中，间断性地执行了引用程序代码，所以能减少系统的停顿时间。但是，因为线程切换和上下文转换的消耗，会使得垃圾回收的总成本上升，造成系统的吞吐量的下降。

分区算法

一般而言，在相同条件下，堆空间越大，一次GC时所需要的时间越长，有关GC产生的停顿也越长。为了更好地控制GC产生的停顿时间，将一块打的内存区域分割成多个小块，根据目标的停顿时间，每次合理地回收若干个小区间，而不是整个堆空间，从而减少一次GC锁产生的停顿。

分代算法将按照对象的生命周期长短划分为两个部分，分区算法将整个堆空间划分成连续的不同的小区间。每一个小区间都独立使用，独立回收。这种算法的好处是可以控制一次回收多少个区间。

三色标记

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

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

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

多标-浮动垃圾

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

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

漏标-读写屏障

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

增量更新就是当黑色对象插入新的指向白色对象的引用关系时,就将这个新插入的引用记录下来,等并发扫描结束之后,再将这些记录过的引用关系中的黑色对象为根,重新扫描一次。这可以简化理解为,黑色对象一旦新插入了指向白色对象的引用之后,它就变回灰色对象了

原始快照就是当灰色对象要删除指向白色对象的引用关系时,就将这个要删除的引用记录下来,在并发扫描结束之后,再将这些记录过的引用关系中的灰色对象为根,重新扫描一次,这样就能扫描到白色的对象,将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来,待下一轮gc的时候重新扫描,这个对象也有可能是浮动垃圾)。

写屏障

给某个对象的成员变量赋值时,其底层代码大概长这样

/**
	@param field 某对象的成员变量，如a.b.d
	@param new_value 新值，如null
*/
void oop_field_store(oop* field,oop new _value){
    *field = new_value;//赋值操作
}

所谓的写屏障，其实就是指在赋值操作前后，加入一些处理：

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

  • 写屏障实现SATB

    当对象B的成员变量的引用发生变化，比如引用消失(a.b.d=null),可以利用写屏障，将B原来成员变量的引用对象D记录下来：

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

  • 写屏障实现增量更新

    当对象A的成员变量的引用发生变化，比如新增引用(a.d=d),可以利用写屏障，将A新的成员变量引用对象D记录下来：

    void post_write_barrier(oop* field,oop new_value){
    remark_set.add(new_value); //记录新引用的对象
}

读屏障

oop oop_field_load(oop* field){
    pre_load_barrier(field); //读屏障-读前操作
    return *field;
}

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

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

现代追踪式(可达性分析)的垃圾回收器几乎都借鉴了三色标记的算法思想,尽管实现的方式不尽相同:比如白色/黑色集合一般都不会岀现(但是有其他体现颜色的地方)、灰色集合可以通过栈队列缓存日志等方式进行实现、遍历方式可以是广度深度遍历等等。

对于读写屏障，以Java HotSpot VM为例，器并发标记时对漏标的处理方案如下：

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

工程实现中,读写屏障还有其他功能,比如写屏障可以用于记录跨代区引用的变化,读屏障可以用于攴持移动对象的并发执行等。功能之外,还有性能的考虑,所以对于选择哪种,每款垃圾回收器都有自己的想法。

为什么G1用SATB？CMS用增量更新

我的理解:SATB相对增量更新效率会髙(当然SATB可能造成更多的浮动垃圾),因为不需要在重新标记阶段再次深度扫描被删除引用对象,而CMS对增量引用的根对象会做深度扫描,G因为很多对象都位于不同的 region,CMS就一块老年代区域,重新深度扫描对象的话G1的代价会比CMS高,所以G1选择SATB不深度扫描对象,只是简单标记,等到下一轮GC再深度扫描。

记忆集与卡表

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

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

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

hotspot使用一种叫做卡表" (Cardtable)的方式实现记忆集,也是目前最常用的一种方式。关于卡表与记忆集的关系,可以类比为Java语言中 HashMap与Map的关系。
卡表是使用一个字节数组实现:CARD_ TABLE[],每个元素对应着其标识的内存区域一块特定大小的内存块,称为“卡页”。

hotspot使用的卡页是2^9大小,即512字节

一个卡页中可包含多个对象,只要有一个对象的字段存在跨代指针,其对应的卡表的元素标识就变成1,表示该元素变脏,否则为0。
GC时,只要筛选本收集区的卡表中变脏的元素加入 GCRoots里。

卡表的维护

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

posted @ 2021-10-26 20:20  程序员清风  阅读(345)  评论(0)  编辑  收藏  举报