Android内存管理(垃圾回收算法相关)

可回收对象的判定

  • 引用计数算法

给对象添加一个引用计数器,每当有一个地方引用它的时候,计数器的值就加1;当引用失效的时候,计数器的值就减1;任何时刻计数器为0的对象是不可能再被引用的。

  这种方法实现简单,判断效率也很高;但是该算法有一个致命的缺点就是 难以解决对象相互引用的问题:试想有两个对象,相互持有对方的引用,而没有别的对象引用到这两者,那么这两个对象就是无用的对象,理应被回收,但是由于他们互相持有对方的引用,因此他们的引用计数器不为0,因此他们不能被回收。

  • 可达性分析算法

为了解决上面循环引用的问题,Java采用了一种全新的算法——可达性分析算法。这个算法的核心思想是,通过一系列称为“GC Roots”的对象作为起始点,从这些结点开始向下搜索,搜索所走过的路径成为“引用链”,当一个对象到GC Roots没有一个对象相连时,则证明此对象是不可用的(不可达)。

在Java语言中,可作为GC Roots的对象包括下面几种:

  • JVM栈(栈帧数据中的本地变量表)中引用的对象。
  • 方法区中类静态属性引用的对象。
  • 方法区中常量引用的对象。
  • Native 方法栈中JNI引用的对象。

需要注意一点,即使在可达性分析算法中不可达对象,也并非是“非死不可”的,要真正宣告一个对象的死亡,至少需要经历两次标记的过程:

如果一个对象在进行可达性分析之后发现没有与GC Roots相连的引用链,那么他将会第一次标记并且**。 当对象没有复写finalize()方法,或者finalize()方法已经被虚拟机调用过,虚拟机讲着两种情况都视为“没有必要执行finalize()方法**”。

如果这个对象被判定为 有必要执行finalize()方法,那么这个对象会被加入一个“F-Queue”队列中,并在稍后由一个虚拟机建立的、优先级低的Finalize线程,去触发这个方法,但并不承诺会等待他运行结束。

finalize()方法是对象逃脱死亡厄运的最后一次机会,稍后的GC会对在“F-Queue”队列中的对象进行第二次小规模的标记;

如果对象要在finalize()中拯救自己,只需要重新与引用链上的对象就行关联即可,那么在第二次标记时它将被移出“即将回收”的集合;

如果对象这个时候还是没有逃脱,那基本上他就真的被回收了。

  • 引用

引用: 在JDK1.2之后,Java将引用分为强引用、软引用、弱引用和虚引用。

无论是引用计数法还是可达性分析算法,判断对象的存活与否都与“引用”有关。在JDK1.2之前,“引用”的解释为:如果reference类型的数据中储存的数值代表的是另外一块内存的起始地址,就称这个数据代表着一个引用。 在JDK1.2之后,Java对引用的概念进行了扩充,将引用分为 强引用、软引用、弱引用、虚引用

强引用: 当我们new一个对象时就是创建了一个具有强引用的对象,如果一个对象具有强引用,垃圾收集器就绝不会回收它。Java虚拟机宁愿抛出OutOfMemoryError异常,使程序异常终止,也不会回收具有强引用的对象来解决内存不足的问题。

软引用: 如果一个对象只具有软引用,当内存不够时,会回收这些对象的内存,回收后如果还是没有足够的内存,就会抛出OutOfMemoryError异常。Java提供了SoftReference类来实现软引用。

弱引用: 弱引用比起软引用具有更短的生命周期,垃圾收集器一旦发现了只具有弱引用的对象,不管当前内存是否足够,都会回收它的内存。Java提供了WeakReference类来实现弱引用。

虚引用: 虚引用并不会决定对象的生命周期,如果一个对象仅持有虚引用,这就和没有任何引用一样,在任何时候都可能被垃圾收集器回收。一个只具有虚引用的对象,被垃圾收集器回收时会收到一个系统通知,这也是虚引用的主要作用。Java提供了PhantomReference类来实现虚引用。

常用的垃圾回收算法

  • 1. 标记-清除算法

标记-清除(Mark-Sweep)算法是现代垃圾回收算法的思想基础。标记-清除算法将垃圾回收分为两个阶段:标记阶段和清除阶段。一种可行的实现是,在标记阶段,首先通过根节点,标记所有从根节点开始的可达对象。因此,未被标记的对象就是未被引用的垃圾对象(好多资料说标记出要回收的对象,其实明白大概意思就可以了)。然后,在清除阶段,清除所有未被标记的对象。 如图:

缺点:

  • 1、效率问题,标记和清除两个过程的效率都不高;
  • 2、空间问题,标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大的对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。
  • 2. 标记-整理算法

标记整理算法类似与标记清除算法,不过它标记完对象后,不是直接对可回收对象进行清理,而是让所有存活的对象都向一端移动,然后直接清理掉边界以外的内存。

缺点:

  • 1、效率问题,(同标记清除算法)标记和整理两个过程的效率都不高;

优点:

  • 1、相对标记清除算法,解决了内存碎片问题。
  • 2、没有内存碎片后,对象创建内存分配也更快速了(可以使用TLAB进行分配)。
  • 3. 复制算法

复制算法可以解决效率问题,它将可用内存按容量划分为大小相等的两块,每次只使用其中的一块,当这一块内存用完了,就将还存活着的对象复制到另一块上面,然后再把已经使用过的内存空间一次清理掉,这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可(还可使用TLAB进行高效分配内存)。

图的上半部分是未回收前的内存区域,图的下半部分是回收后的内存区域。通过图,我们发现不管回收前还是回收后都有一半的空间未被利用。

优点 效率高,没有内存碎片 缺点:

  • 1、浪费一半的内存空间
  • 2、复制收集算法在对象存活率较高时就要进行较多的复制操作,效率将会变低。
  • 4. 分代收集算法

当前商业虚拟机都是采用分代收集算法,它根据对象存活周期的不同将内存划分为几块,一般是把Java堆分为新生代和老年代,然后根据各个年代的特点采用最适当的收集算法,在新生代中,每次垃圾收集都发现有大批对象死去,只有少量存活,就选用复制算法,而老年代因为对象存活率高,没有额外空间对它进行分配担保,就必须使用“标记清理”或者“标记整理”算法来进行回收。

图的左半部分是未回收前的内存区域,右半部分是回收后的内存区域。

对象分配策略:

    1. 对象优先在Eden区域分配,如果对象过大直接分配到Old区域。
    1. 长时间存活的对象进入到Old区域。

改进复制算法: 现在的商业虚拟机都采用这种收集算法来回收新生代,IBM公司的专门研究表明,新生代中的对象98%是“朝生夕死”的,所以并不需要按照1:1的比例来划分内存空间,而是将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor 。当回收时,将Eden和Survivor中还存活着的对象一次性地复制到另外一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。 HotSpot虚拟机默认Eden和Survivor的大小比例是8:1,也就是每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的内存会被“浪费”。当然,98%的对象可回收只是一般场景下的数据,我们没有办法保证每次回收都只有不多于10%的对象存活,当Survivor空间不够用时,需要依赖其他内存(这里指老年代)进行分配担保(Handle Promotion)。

results matching ""

    No results matching ""