Java垃圾回收算法

2019-06-17  本文已影响0人  星月下的青草

在Java虚拟机运行时区域的各个部分中,程序计数器,虚拟机栈,本地方法栈声明周期与生成对应线程的生命周期:栈中的栈帧都是随着方法的进入和退出而执行者出栈和入栈操作。每个栈帧的内存基本上是在类结构确定下来时就已知,所以这个几个区域的内存分配和回收都具备确定性,在这个几个区域内就不需要过多考虑内存回收的问题,因为方法结束或者线程结束时,内存自然就跟随者回收了。 而Java堆和方法区不一样,一个接口中的多个类实现需要的内存可能不一样,一个方法中的多个分支需要的内存也可能不一样,我们只有在程序处于运行期间时才知道会创建哪些对象,这个部分的内存的分配和回收都是动态的,我们只重点关注这部分。

对象已死?

内存回收,就需要确保要回收的对象在其他地方不会再被使用。

引用计数法

引用计数法

给对象添加一个引用计数器,当被引用时加1 ,引用失效减1,任何时刻当该对象的引用计数器值为0 时,就表示对象不再内使用,可以回收。

优点

实现简单,效率高。

缺点

无法解决对象之间循环引用的问题。这也是Java语言没有采用引用计数算法来管理内存。

可达性分析算法

可达性分析算法判断对象是可回收,通过一些"GCRoots"对象作为起点,从这些节点开始往下搜索,所走过的路径称为引用链(ReferenceChain),当一个对象到GCRoots没有任何引用链连接的时候,说明这个对象是从GCRoots不可达的,则证明此对象不可用。

image.png

GCRoots对象包括

垃圾回收算法

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

顾名思义,算法分为两阶段,标记和清除。它是最基础的手机算法。 首先标记出所有需要回收的对象,在标记完成后统一的回收所有被标记的对象。

我们通过下图看一下标记清除算法的大致过程:

图例:

image.png

回收前标记状态:

image.png

回收后清除状态:

image.png

标记清除算法有两个不足:

复制算法 (Copying)

为了解决标记清除算法的效率问题,出现了复制的收集算法。它将可用的内存空间划分为两个大小相等的区域,每次只是用其中的一块,当这一块内存用完了,就将还存活的对象复制到另一块上,然后把使用过的内存一次清理,这样使得每次都是对整个半区进行内存回收。

优点

内存分配时也不用考虑内存碎片等情况,只要移动堆顶指针,按顺序分配即可,实现简单,运行高效。

缺点

该算法的代价是将内存缩小为原来的一半,代价太高。

回收前内存状态:

image.png

回收后内存状态:

image.png

IBM公司的研究表明:新生代中的对象98%是“朝生夕死”的,所以不需要按照1:1的比例来划分内存空间,而是将内存分为一块较大的eden 空间和两块较小的survivor 空间,每次使用eden和其中的一个survivor。

[图片上传失败...(image-3f0533-1560778119254)]

当回收时将eden和survivor中还存活的对象一次性的复制到另一块 survivor空间上,最后清理掉使用过的eden和survivor空间。HotSpot虚拟机默认eden和survivor 的比例为8:1,也就是每次新生代中可用内存空间为整个新生代容量的90%,只用10%会被浪费。

当然,98%的对象可回收只是一般场景下的数据,无法保证每次回收都只有不多于10%的对象存活,当survivor空间不够的时候,需要依赖老年代进行分配担保。

内存分配担保,当另一个新生代survivor空间没有足够的空间去存放上次新生代收集下来的存活对象,这些对象将直接通过分配担保机制进入老年代。

标记-整理(Mark-Compact)算法

复制算法在对象存活率较高时就要进行较多的复制操作,效率会变低。

标记-整理算法,标记的过程,和标记-清除的标记过程一样,但后续的整理是让所有存活的对象,都向一端移动,然后直接清理掉端边界以外的内存。

整理前的内存状态:

image.png

整理后的内存状态:

image.png

分代收集算法

根据对象的存活周期不同将内存划分为新生代和老年代,这样可以根据各个年代的特点采用适当的收集算法。

新生代的中每次垃圾收集中会发现有大批对象死区,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。

老年代中因为对象的存活率高,没有额外的控件对它进行分配担保,就必须使用“标记-清扫”或者“标记-整理”算法来进行回收。

上一篇下一篇

猜你喜欢

热点阅读