`

java 垃圾回收 常用算法

阅读更多

垃圾收集基础

Java 语言的一大特点就是可以进行自动垃圾回收处理,而无需开发人员过于关注系统资源,例如内存资源的释放情况。自动垃圾收集虽然大大减轻了开发人员的工作量,但是也增加了软件系统的负担。

拥有垃圾收集器可以说是 Java 语言与 C++语言的一项显著区别。在 C++语言中,程序员必须小心谨慎地处理每一项内存分配,且内存使用完后必须手工释放曾经占用的内存空间。当内存释放不够完全时,即存在分配但永不释放的内存块,就会引起内存泄漏,严重时甚至导致程序瘫痪。

以下列举了垃圾回收器常用的算法及实验原理:

  • 引用计数法 (Reference Counting)

引用计数器在微软的 COM 组件技术中、Adobe 的 ActionScript3 种都有使用。

引用计数器的实现很简单,对于一个对象 A,只要有任何一个对象引用了 A,则 A 的引用计数器就加 1,当引用失效时,引用计数器就减 1。只要对象 A 的引用计数器的值为 0,则对象 A 就不可能再被使用。

引用计数器的实现也非常简单,只需要为每个对象配置一个整形的计数器即可。但是引用计数器有一个严重的问题,即无法处理循环引用的情况。因此,在 Java 的垃圾回收器中没有使用这种算法。

一个简单的循环引用问题描述如下:有对象 A 和对象 B,对象 A 中含有对象 B 的引用,对象 B 中含有对象 A 的引用。此时,对象 A 和对象 B 的引用计数器都不为 0。但是在系统中却不存在任何第 3 个对象引用了 A 或 B。也就是说,A 和 B 是应该被回收的垃圾对象,但由于垃圾对象间相互引用,从而使垃圾回收器无法识别,引起内存泄漏。

关键词:被引用对象计数+1,引用失效计数-1,但是循环引用就有问题了。

  • 标记-清除算法 (Mark-Sweep)

标记-清除算法将垃圾回收分为两个阶段:标记阶段和清除阶段。一种可行的实现是,在标记阶段首先通过根节点,标记所有从根节点开始的较大对象。因此,未被标记的对象就是未被引用的垃圾对象。然后,在清除阶段,清除所有未被标记的对象。该算法最大的问题是存在大量的空间碎片,因为回收后的空间是不连续的。在对象的堆空间分配过程中,尤其是大对象的内存分配,不连续的内存空间的工作效率要低于连续的空间。

关键词:从根开始扫描,被引用对象被标记,未被引用的对象在清除阶段被删除,但是删除后的内存不连续了,不利于大对象的内存分配

  • 复制算法 (Copying)

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

如果系统中的垃圾对象很多,复制算法需要复制的存活对象数量并不会太大。因此在真正需要垃圾回收的时刻,复制算法的效率是很高的。又由于对象在垃圾回收过程中统一被复制到新的内存空间中,因此,可确保回收后的内存空间是没有碎片的。该算法的缺点是将系统内存折半。

Java 的新生代串行垃圾回收器中使用了复制算法的思想。新生代分为 eden 空间、from 空间、to 空间 3 个部分。其中 from 空间和 to 空间可以视为用于复制的两块大小相同、地位相等,且可进行角色互换的空间块。from 和 to 空间也称为 survivor 空间,即幸存者空间,用于存放未被回收的对象。

在垃圾回收时,eden 空间中的存活对象会被复制到未使用的 survivor 空间中 (假设是 to),正在使用的 survivor 空间 (假设是 from) 中的年轻对象也会被复制到 to 空间中 (大对象,或者老年对象会直接进入老年带,如果 to 空间已满,则对象也会直接进入老年代)。此时,eden 空间和 from 空间中的剩余对象就是垃圾对象,可以直接清空,to 空间则存放此次回收后的存活对象。这种改进的复制算法既保证了空间的连续性,又避免了大量的内存空间浪费。

关键词:两个内存空间,复制引用对象至另一个内存空间,删除剩余全部对象,需要建立在存活对象少,垃圾对象多的前提下,且内存折半了。

  • 标记-压缩算法 (Mark-Compact)

复制算法的高效性是建立在存活对象少、垃圾对象多的前提下的。这种情况在年轻代经常发生,但是在老年代更常见的情况是大部分对象都是存活对象。如果依然使用复制算法,由于存活的对象较多,复制的成本也将很高。

标记-压缩算法是一种老年代的回收算法,它在标记-清除算法的基础上做了一些优化。也首先需要从根节点开始对所有可达对象做一次标记,但之后,它并不简单地清理未标记的对象,而是将所有的存活对象压缩到内存的一端。之后,清理边界外所有的空间。这种方法既避免了碎片的产生,又不需要两块相同的内存空间,因此,其性价比比较高。

关键词:从根开始扫描,将存活对象压缩至内存一端,然后清理边界所有内存空间

  • 增量算法 (Incremental Collecting)

在垃圾回收过程中,应用软件将处于一种 CPU 消耗很高的状态。在这种 CPU 消耗很高的状态下,应用程序所有的线程都会挂起,暂停一切正常的工作,等待垃圾回收的完成。如果垃圾回收时间过长,应用程序会被挂起很久,将严重影响用户体验或者系统的稳定性。

增量算法的基本思想是,如果一次性将所有的垃圾进行处理,需要造成系统长时间的停顿,那么就可以让垃圾收集线程和应用程序线程交替执行。每次,垃圾收集线程只收集一小片区域的内存空间,接着切换到应用程序线程。依次反复,直到垃圾收集完成。使用这种方式,由于在垃圾回收过程中,间断性地还执行了应用程序代码,所以能减少系统的停顿时间。但是,因为线程切换和上下文转换的消耗,会使得垃圾回收的总体成本上升,造成系统吞吐量的下降。

关键词:垃圾回收时应用程序被挂起,交替垃圾回收和应用程序执行,减少系统停顿时间。

  • 分代 (Generational Collecting)

根据垃圾回收对象的特性,不同阶段最优的方式是使用合适的算法用于本阶段的垃圾回收,分代算法即是基于这种思想,它将内存区间根据对象的特点分成几块,根据每块内存区间的特点,使用不同的回收算法,以提高垃圾回收的效率。以 Hot Spot 虚拟机为例,它将所有的新建对象都放入称为年轻代的内存区域,年轻代的特点是对象会很快回收,因此,在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活,对象就会被放入称为老生代的内存空间。在老生代中,几乎所有的对象都是经过几次垃圾回收后依然得以幸存的。因此,可以认为这些对象在一段时期内,甚至在应用程序的整个生命周期中,将是常驻内存的。如果依然使用复制算法回收老生代,将需要复制大量对象。再加上老生代的回收性价比也要低于新生代,因此这种做法也是不可取的。根据分代的思想,可以对老年代的回收使用与新生代不同的标记-压缩算法,以提高垃圾回收效率。

关键词:不同代使用不同算法,新建对象放入年轻代内存->对象很快会回收,使用复制算法, 几次回收依然存活的放入老年代内存 ->使用标记-压缩算法

从不同角度分析垃圾收集器,可以将其分为不同的类型。

1. 按线程数分,可以分为串行垃圾回收器和并行垃圾回收器。串行垃圾回收器一次只使用一个线程进行垃圾回收;并行垃圾回收器一次将开启多个线程同时进行垃圾回收。在并行能力较强的 CPU 上,使用并行垃圾回收器可以缩短 GC 的停顿时间。

2. 按照工作模式分,可以分为并发式垃圾回收器和独占式垃圾回收器。并发式垃圾回收器与应用程序线程交替工作,以尽可能减少应用程序的停顿时间;独占式垃圾回收器 (Stop the world) 一旦运行,就停止应用程序中的其他所有线程,直到垃圾回收过程完全结束。

3. 按碎片处理方式可分为压缩式垃圾回收器和非压缩式垃圾回收器。压缩式垃圾回收器会在回收完成后,对存活对象进行压缩整理,消除回收后的碎片;非压缩式的垃圾回收器不进行这步操作。

4. 按工作的内存区间,又可分为新生代垃圾回收器和老年代垃圾回收器。

可以用以下指标评价一个垃圾处理器的好坏。

吞吐量:指在应用程序的生命周期内,应用程序所花费的时间和系统总运行时间的比值。系统总运行时间=应用程序耗时+GC 耗时。如果系统运行了 100min,GC 耗时 1min,那么系统的吞吐量就是 (100-1)/100=99%。

垃圾回收器负载:和吞吐量相反,垃圾回收器负载指来记回收器耗时与系统运行总时间的比值。

停顿时间:指垃圾回收器正在运行时,应用程序的暂停时间。对于独占回收器而言,停顿时间可能会比较长。使用并发的回收器时,由于垃圾回收器和应用程序交替运行,程序的停顿时间会变短,但是,由于其效率很可能不如独占垃圾回收器,故系统的吞吐量可能会较低。

垃圾回收频率:指垃圾回收器多长时间会运行一次。一般来说,对于固定的应用而言,垃圾回收器的频率应该是越低越好。通常增大堆空间可以有效降低垃圾回收发生的频率,但是可能会增加回收产生的停顿时间。

反应时间:指当一个对象被称为垃圾后多长时间内,它所占据的内存空间会被释放。

堆分配:不同的垃圾回收器对堆内存的分配方式可能是不同的。一个良好的垃圾收集器应该有一个合理的堆内存区间划

 

 

Java的内存分布

在JVM中,内存是按照分代进行组织的。

其中,堆内存分为年轻代和年老代,非堆内存主要是Permanent区域,主要用于存储一些类的元数据,常量池等信息。而年轻代又分为两种,一种是Eden区域,另外一种是两个大小对等的Survivor区域。之所以将Java内存按照分代进行组织,主要是基于这样一个“弱假设” - 大多数对象都在年轻时候死亡。同时,将内存按照分代进行组织,使得我们可以在不同的分代上使用不同的垃圾回收算法,使得整个内存的垃圾回收更加有效。

年轻代的垃圾回收

在年轻代上采用的垃圾回收算法是“Mark-Copy”算法,并不同于我们前面所了解的任何一种基本垃圾回收算法,但是Mark算法是一样的,基于根对象找到所有的可达对象,具体可看Mark-Sweep算法中的Mark步骤. 而对于Copy算法,它仅仅是简单的将符合一定年龄的对象从一个分代拷贝到另一个分代。具体的回收过程如下:

首先,新对象的内存分配都是先在Eden区域中进行的,当Eden区域的空间不足于分配新对象时,就会触发年轻代上的垃圾回收(发生在Eden和Survivor内存区域上),我们称之为"minor garbage collection".同时,每个对象都有一个“年龄”,这个年龄实际上指的就是该对象经历过的minor gc的次数。如图1所示,当对象刚分配到Eden区域时,对象的年龄为“0”,当minor gc被触发后,所有存活的对象(仍然可达对象)会被拷贝到其中一个Survivor区域,同时年龄增长为“1”。并清除整个Eden内存区域中的非可达对象。

当第二次minor gc被触发时(如图2所示),JVM会通过Mark算法找出所有在Eden内存区域和Survivor1内存区域存活的对象,并将他们拷贝到新的Survivor2内存区域(这也就是为什么需要两个大小一样的Survivor区域的原因),同时对象的年龄加1. 最后,清除所有在Eden内存区域和Survivor1内存区域的非可达对象。

当对象的年龄足够大(这个年龄可以通过JVM参数进行指定,这里假定是2),当minor gc再次发生时,它会从Survivor内存区域中升级到年老代中,如图3所示。

其实,即使对象的年龄不够大,但是Survivor内存区域中没有足够的空间来容纳从Eden升级过来的对象时,也会有部分对象直接升级到Tenured内存区域中。

年老代的垃圾回收

当minor gc发生时,又有对象从Survivor区域升级到Tenured区域,但是Tenured区域已经没有空间容纳新的对象了,那么这个时候就会触发年老代上的垃圾回收,我们称之为"major garbage collection".

而在年老代上选择的垃圾回收算法则取决于JVM上采用的是什么垃圾回收器。通过的垃圾回收器有两种:Parallel Scavenge(PS) 和Concurrent Mark Sweep(CMS)。这两种垃圾回收器的不同更多的是体现在年老代的垃圾回收过程中,年轻代的垃圾回收过程在这两种垃圾回收器中基本上是一致的。

就像其名字所表示的那样,Parallel Scavenge垃圾回收器在执行垃圾回收时使用了多线程来一起进行垃圾回收,这样可以提高垃圾回收的效率。而Concurrent Mark Sweep垃圾回收器在进行垃圾回收时,应用程序可以同时运行。

Parallel Scavenge

PS垃圾回收器在年老代上采用的垃圾回收算法可以看作是标记-清除算法标记-压缩算法的结合体。

首先,PS垃圾回收器先是会在年老代上使用标记-清除算法来回收掉非可达对象所占有的空间,但是我们知道,标记清除算法的一个缺陷就是它会引起内存碎片问题。继而有可能会引发连续的major gc。假设当前存在的内存碎片有10M,但最大的内存碎片只能容纳2M的对象,这个时候如果有一个3M的对象从Survivor区域升级到Tenured区域,那Tenured区域也没有办法存放这个3M的对象。结果就是不断的触发major gc,直到Out of Memory。所以,PS垃圾回收器在清除非可达对象后,还会进行一次compact,来消除内存碎片。

Concurrent Mark Sweep

CMS垃圾收集器相比于PS垃圾收集器,它成功的减少了垃圾收集时暂停应用程序的时间,因为CMS在进行垃圾收集时,应用程序是可以并行运行的。下面让我们来看看它是怎么做到的。

从它的名字可以看出,CMS垃圾收集器在年老代上采用的垃圾回收算法是标记-清除算法。但是,它跟标准的标记-清除算法略有不同。它主要分为四个阶段:

  1. Initial Mark阶段 - 这个阶段是Stop-The-World的,它会暂停应用程序的运行,但是在这里阶段,它不会标记出在Tenured区域中所有的可达对象。它只会从根对象开始出发,标记到根对象的第一层孩子节点即停止。然后恢复应用程序的运行。所以,这个暂停应用程序的时间是很短的。
  2. Concurrent Mark阶段 - 在这个阶段中,CMS垃圾回收器以Initial Mark阶段标记的节点为根对象,重新开始标记Tenured区域中的可达对象。当然,在这个阶段中是不需要暂停应用程序的。这也是它称为"Concurrent Mark"的原因。这同时也造成了一个问题,那就是由于CMS垃圾回收器和应用程序同时运行,Concurrent Mark阶段它并不保证在Tenured区域的可达对象都被标记了 - 应用程序一直在分配新对象。
  3. Remark阶段 - 由于Concurrent Mark阶段它并不保证在Tenured区域的可达对象都被标记了,所以我们需要再次暂停应用程序,确保所有的可达对象都被标记。为了加快速度,这里也采用了多线程来同时标记可达对象。
  4. Concurrent Sweep阶段 - 最后,恢复应用程序的执行,同时CMS执行sweep,来清除所有非可达对象所占用的内存空间。

从下图可以看到PS和CMS垃圾收集器的区别:

黑色箭头代表应用程序的运行,绿色箭头代表CMS垃圾收集器的运行。一根线条表示单线程,多个线条表示多线程。

所以,相比于PS垃圾收集器,CMS垃圾收集器成功的减少了应用程序暂时的时间。

Garbage First(G1)垃圾收集器

但是很不幸的是,CMS垃圾收集器虽然减少了暂停应用程序的运行时间,但是由于它没有Compact阶段,它还是存在着内存碎片问题。于是,为了去除内存碎片问题,同时又保留CMS垃圾收集器低暂停时间的优点,JAVA7发布了一个新的垃圾收集器 - G1垃圾收集器。它会在未来逐步替换掉CMS垃圾收集器。

G1垃圾收集器和CMS垃圾收集器有几点不同。首先,最大的不同是内存的组织方式变了。Eden,Survivor和Tenured等内存区域不再是连续的了,而是变成了一个个大小一样的region - 每个region从1M到32M不等。

一个region有可能属于Eden,Survivor或者Tenured内存区域。图中的E表示该region属于Eden内存区域,S表示属于Survivor内存区域,T表示属于Tenured内存区域。图中空白的表示未使用的内存空间。G1垃圾收集器还增加了一种新的内存区域,叫做Humongous内存区域,如图中的H块。这种内存区域主要用于存储大对象-即大小超过一个region大小的50%的对象。

在G1垃圾收集器中,年轻代的垃圾回收过程跟PS垃圾收集器和CMS垃圾收集器差不多,新对象的分配还是在Eden region中,当所有Eden region的大小超过某个值时,触发minor gc,回收Eden region和Survivor region上的非可达对象,同时升级存活的可达对象到对应的Survivor region和Tenured region上。对象从Survivor region升级到Tenured region依然是取决于对象的年龄。

对于年老代上的垃圾收集,G1垃圾收集器也分为4个阶段,基本跟CMS垃圾收集器一样,但略有不同:

  1. Initial Mark阶段 - 同CMS垃圾收集器的Initial Mark阶段一样,G1也需要暂停应用程序的执行,它会标记从根对象出发,在根对象的第一层孩子节点中标记所有可达的对象。但是G1的垃圾收集器的Initial Mark阶段是跟minor gc一同发生的。也就是说,在G1中,你不用像在CMS那样,单独暂停应用程序的执行来运行Initial Mark阶段,而是在G1触发minor gc的时候一并将年老代上的Initial Mark给做了。
  2. Concurrent Mark阶段 - 在这个阶段G1做的事情跟CMS一样。但G1同时还多做了一件事情,那就是,如果在Concurrent Mark阶段中,发现哪些Tenured region中对象的存活率很小或者基本没有对象存活,那么G1就会在这个阶段将其回收掉,而不用等到后面的clean up阶段。这也是Garbage First名字的由来。同时,在该阶段,G1会计算每个 region的对象存活率,方便后面的clean up阶段使用 。
  3. Remark阶段 - 在这个阶段G1做的事情跟CMS一样, 但是采用的算法不同,G1采用一种叫做SATB(snapshot-at-the-begining)的算法能够在Remark阶段更快的标记可达对象。
  4. Clean up/Copy阶段 - 在G1中,没有CMS中对应的Sweep阶段。相反 它有一个Clean up/Copy阶段,在这个阶段中,G1会挑选出那些对象存活率低的region进行回收,这个阶段也是和minor gc一同发生的,如下图所示:

从上可以看到,由于Initial Mark阶段Clean up/Copy阶段都是跟minor gc同时发生的,相比于CMS,G1暂停应用程序的时间更少,从而提高了垃圾回收的效率。



文/可文分身(简书作者)
原文链接:http://www.jianshu.com/p/778dd3848196
著作权归作者所有,转载请联系作者获得授权,并标注“简书作者”。

转自: https://www.ibm.com/developerworks/cn/java/j-lo-JVMGarbageCollection/

分享到:
评论

相关推荐

    autocorr-vi-5.3.6.1-24.el7.noarch.rpm.zip

    文件太大放服务器下载,请务必到电脑端资源详情查看然后下载

    ssm旅游资源网站.zip

    ssm旅游资源网站.zip

    bc-1.06.95-13.el7.x86_64.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    clutter-gtk-1.8.4-1.el7.x86_64.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    autocorr-sv-5.3.6.1-24.el7.noarch.rpm.zip

    文件太大放服务器下载,请务必到电脑端资源详情查看然后下载

    基于分片技术实现高性能区块链go源码+项目说明(高分毕设).zip

    基于分片技术实现高性能区块链的Go源码和项目说明,是一个专为计算机、数学及电子信息等专业学生设计的毕业设计项目。该项目利用先进的区块链技术和分片机制,旨在解决传统区块链在大规模数据处理中的性能瓶颈问题。本项目通过引入分片技术,将区块链网络划分为多个较小的分片,每个分片独立处理一部分交易和数据。这种架构不仅提高了系统的并行处理能力,还显著提升了整体的交易吞吐量和网络性能。同时,项目还详细阐述了如何实现跨分片的数据同步与一致性保证,确保了系统的安全性和可靠性。此外,项目还包括完整的代码实现和详细的项目说明文档,为学习者提供了从理论到实践的全面指导。无论是区块链技术的初学者还是有一定基础的开发者,都可以通过这个项目深入了解分片技术的实现原理和应用方法。总的来说,这是一个集学习、实践与创新于一体的综合性项目,适合作为相关专业课程设计、期末大作业或毕业设计的优选题目。

    福聚苑社区团购.zip

    福聚苑社区团购.zip

    apr-util-nss-1.5.2-6.el7.x86_64.rpm.zip

    文件太大放服务器下载,请务必到电脑端资源详情查看然后下载

    bzip2-devel-1.0.6-13.el7.i686.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    batik-slideshow-1.8-0.12.svn1230816.el7.noarch.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    YT118-USB转串口(TYPE-C).zip

    该单片机项目可作为课程设计和期末大作业或者毕设,项目完整,有原理图和代码,需要的自行下载即可!

    babl-devel-0.1.10-10.el7.x86_64.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    java小游戏,滚木块.zip学习资源代码

    java java小游戏,滚木块.zip学习资源代码

    agg-devel-2.5-18.el7.i686.rpm.zip

    文件太大放服务器下载,请务必到电脑端资源详情查看然后下载

    cockpit-ws-195.10-1.el7.centos.x86_64.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    职能经历丰富度/职业数量/复合职能数据集(2008-2022年).txt

    因文件较多,数据存放网盘,txt文件内包含下载链接及提取码,永久有效。失效会第一时间进行补充。样例数据及详细介绍参见文章:https://blog.csdn.net/T0620514/article/details/144224915

    ca-certificates-2020.2.41-70.0.el7_8.noarch.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    bash-doc-4.2.46-34.el7.x86_64.rpm.zip

    文件放服务器下载,请务必到电脑端资源详情查看然后下载

    avahi-gobject-devel-0.6.31-20.el7.x86_64.rpm.zip

    文件太大放服务器下载,请务必到电脑端资源详情查看然后下载

    Redis持久化策略与AOF机制详解

    内容概要:本文详细介绍了Redis的持久化策略,特别是RDB(Redis Database Backup)和AOF(Append Only File)两种主要的持久化方法。RDB通过在某个时间点创建数据集的快照来实现数据持久化,其优点包括数据恢复快、占用资源少、数据完整性高等。AOF通过记录每个写操作命令来实现数据的持久化,其优点包括数据安全性高、数据恢复完整、可配置性强等。文章还探讨了RDB和AOF的优缺点,并给出了具体的配置示例。此外,文章讨论了AOF在主从复制和集群模式下的应用以及在高并发场景下的性能调优和数据安全的最佳实践。 适合人群:具备Redis基础知识的技术人员、运维人员。 使用场景及目标:理解和掌握Redis的持久化机制,以便在实际生产环境中选择合适的持久化策略,提高数据的安全性和系统的可靠性。 阅读建议:读者应该重点关注RDB和AOF的具体实现原理及其优缺点,结合自己的业务需求选择合适的方法。在高可用和高并发环境下,需要特别注意AOF的配置和调优策略。

Global site tag (gtag.js) - Google Analytics