在Java虚拟机运行时区域的各个部分中,程序计数器,虚拟机栈,本地方法栈声明周期与生成对应线程的生命周期:栈中的栈帧都是随着方法的进入和退出而执行者出栈和入栈操作。每个栈帧的内存基本上是在类结构确定下来时就已知,所以这个几个区域的内存分配和回收都具备确定性,在这个几个区域内就不需要过多考虑内存回收的问题,因为方法结束或者线程结束时,内存自然就跟随者回收了。 而Java堆和方法区不一样,一个接口中的多个类实现需要的内存可能不一样,一个方法中的多个分支需要的内存也可能不一样,我们只有在程序处于运行期间时才知道会创建哪些对象,这个部分的内存的分配和回收都是动态的,我们只重点关注这部分。
对象已死?
内存回收,就需要确保要回收的对象在其他地方不会再被使用。
引用计数法
引用计数法:
给对象添加一个引用计数器,当被引用时加1 ,引用失效减1,任何时刻当该对象的引用计数器值为0 时,就表示对象不再内使用,可以回收。
优点
实现简单,效率高。
缺点
无法解决对象之间循环引用的问题。这也是Java语言没有采用引用计数算法来管理内存。
可达性分析算法
可达性分析算法判断对象是可回收,通过一些"GCRoots"对象作为起点,从这些节点开始往下搜索,所走过的路径称为引用链(ReferenceChain),当一个对象到GCRoots没有任何引用链连接的时候,说明这个对象是从GCRoots不可达的,则证明此对象不可用。
image.pngGCRoots对象包括:
-
虚拟机栈(栈帧中的本地变量表)中的引用的对象。
-
方法区域中的类静态属性引用的对象。
-
方法区域中常量引用的对象。
-
本地方法栈中JNI(Native方法)的引用的对象。
垃圾回收算法
标记-清除(Mark-Sweep)算法
顾名思义,算法分为两阶段,标记和清除。它是最基础的手机算法。 首先标记出所有需要回收的对象,在标记完成后统一的回收所有被标记的对象。
我们通过下图看一下标记清除算法的大致过程:
图例:
image.png回收前标记状态:
image.png回收后清除状态:
image.png标记清除算法有两个不足:
-
效率 ,标记 和清除两个过程的效率都不高
-
空间问题,从上面的过程可以看到,会产生大量的不连续的空间内存碎片,空间碎片会导致以后在程序运行过程中分配较大对象时,无法找到连续的内存而不得不提前出发另一次gc。
复制算法 (Copying)
为了解决标记清除算法的效率问题,出现了复制的收集算法。它将可用的内存空间划分为两个大小相等的区域,每次只是用其中的一块,当这一块内存用完了,就将还存活的对象复制到另一块上,然后把使用过的内存一次清理,这样使得每次都是对整个半区进行内存回收。
优点:
内存分配时也不用考虑内存碎片等情况,只要移动堆顶指针,按顺序分配即可,实现简单,运行高效。
缺点:
该算法的代价是将内存缩小为原来的一半,代价太高。
回收前内存状态:
image.png回收后内存状态:
image.pngIBM公司的研究表明:新生代中的对象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分代收集算法
根据对象的存活周期不同将内存划分为新生代和老年代,这样可以根据各个年代的特点采用适当的收集算法。
新生代的中每次垃圾收集中会发现有大批对象死区,只有少量存活,那就选用复制算法,只需要付出少量存活对象的复制成本就可以完成收集。
老年代中因为对象的存活率高,没有额外的控件对它进行分配担保,就必须使用“标记-清扫”或者“标记-整理”算法来进行回收。
网友评论