Android小知识-内存回收机制

通过下图,知道Android系统中最近分配的对象会存放在Young Generation区域。对象在某个时机触发GC回收垃圾,而没有回收的就根据不同规则,有可能被移动到Old Generation,最后累计一定时间再移动到PermanentGeneration区域。系统会根据内存中不同的内存数据类型分别执行不同的GC操作。GC通过确定对象是否被活动对象引用来确定是否收集该对象,进而动态回收无任何引用的对象占据的内存空间。

图中整个内存分为三个区域:年轻代、老年代以及持久代。

1、Young Generation

年轻代分为三个区,一个Eden区,另外两个S0和S1都是Survivor区(S0和S1只是为了说明,两者实质上一样)。程序中生成的大部分新的对象都在Eden区,当Eden区满时,还存活的对象将被复制到其中一个Survivor区,当此Survivor区的对象占用空间满时,此区存活的对象又被复制到另一个Survivor区,当这个Survivor区也满时,从第一个Survivor区复制过来的并且此时还存活的对象,将被复制到老年代。

2、Old Generation

老年代存放的是上面年轻代复制过来的对象,也就是在年轻代中还存活的对象,并且区满了复制过来的。一般来说,年老代中的对象生命周期都比较长。

3、Permanent Generation

用于存放静态的类和方法,持久代对垃圾回收没有显著的影响。

内存对象的处理过程如下:

  1. 对象创建后在Eden区。

  2. 执行GC时,如果对象仍然存活,则复制到S0区。

  3. 当S0区满时,该区存活对象将复制到S1区,然后S0区清空,接下来SO和S1角色互换。

  4. 当第3步达到一定次数后,存活对象将被复制到Old Generation。

  5. 当这个对象在Old Generation区停留的时间达到一定程度时,它会被移动到Old Generation,最后累积一定时间再移动到Permanent Generation区域。Permanent Generation区域存放一些静态文件,如Java类等。

系统在Young Generation、Old Generation上采用不同的回收机制。每一个Generation的内存区域都有固定的大小。随着新的对象陆续被分配到此区域,当对象总的大小临近这一级别内存区域的阈值时,会触发GC操作,以便腾出空间来存放其它新的对象。

执行GC占用的时间和它发生在哪一个Generation也有关系,Young Generation中的每次GC操作时间最短的,Old Generation其次,Permanent Generation最长。同时GC的执行时间也和当前Generation中的对象数量有关,Generation中的对象数量越多,执行时间越长。

Young Generation通常存活时间较短,因此基于Copying算法来回收,所谓Copying算法,就是扫描出存活的对象,并复制到一块新的完全未使用的空间中,对应于Young Generation,就是在Eden、FromSpace或ToSpace之间copy。新生代采用空闲指针的方式来控制GC触发,指针保持最后一个分配的对象在Young Generation区间的位置,当有新的对象要分配内存时,用于检查空间是否足够,不够就触发GC。当连续分配对象时,对象会逐渐从Eden到Survivor,最后到Old Generation。

Old Generation与Young Generation不同,对象存活的时间比较长,比较稳定,因此采用标记算法来回收。所谓标记,就是扫描出存活的对象,然后再回收未被标记的对象,回收后对空出的空间要么合并,要么标记出来便于下次分配,以减少内存碎片带来的效率损耗。

在Android系统中,GC有以下三种类型:

  • kGcCauseForAlloc:在分配内存时发现内存不够的情况下引起的GC,这种情况下的GC会Stop World。Stop World时由于并发GC时,其他线程都会停止,知道GC完成。

  • kGcCauseBackground:当内存达到一定的阈值时触发GC,这个时候时一个后台GC,不会引起Stop World。

  • kGcCauseExplicit:显示调用时进行的GC,如果ART打开了这个选项,在system.gc时会进行GC。

分析下面这段虚拟机打印出来的日志

D/dalvikvm(7030):GC_CONCURRENT freed 1049k, 60% free 2341k/9351k, external 3502k/6261k, paused 3ms 3ms

freed 1049k表面在这次GC中回收了多少内存。

60% free 2341k/9351k是Heap的一些统计数据,表面这次回收后60%的Heap可用,存活的对象大小为2341KB,Heap大小是9351 KB。

external 3502k/6261k是Native Memory的数据,存放位图数据或者堆以外内存之类的。第一个数字表面Native Memory中已经分类多少内存,第二个值有点类似一个浮动的阈值,表面分配内存达到这个值,系统就会触发一次GC进行内存回收。

paused 3ms 3ms表面GC暂停的时间。

GC_CONCURRENT是当前GC时的类型,在Android的虚拟机中GC日志有以下几种类型:

  • GC_CONCURRENT:当应用进程中的Heap内存占用上涨时,避免因Heap内存满了而触发的GC。

  • GC_FOR_MALLOC:这是由于Concurrent GC没有及时执行完,而应用又需要分配更多的内存,这时不得不停下来进行Malloc GC。

  • GC_EXTERNAL_ALLOC:这是为external分配的内存执行达到GC。

  • GC_HPROF_DUMP_HEAP:创建一个HPROF profile的时候执行。

  • GC_EXPLICIT:显式地调用了System.gc()。一般来说,可以信任系统的GC机制,尽量不去显式调用System.gc(),减少不必要的系统开销,影响应用的流畅度。

在ART模式下日志多了一个Large Object Space(大对象占用的空间),这部分内存并不是分配在堆上的,但仍属于应用程序内存空间,主要用来管理Bitmap等占内存大的对象,避免因分配大内存导致频繁GC。

在Dalvik虚拟机下,GC的操作都是并发的,也就意味着每次触发GC都会导致其他线程暂停工作(包括UI线程)。而在ART模式下,在GC时,不像Dalvik仅有一种回收算法,ART在不同的情况下会选择不同的回收算法,比如Alloc内存不够时会采用非并发GC,但在Alloc后,发现内存达到一定阈值时又会触发并发GC。所以在ART环境下并不是所有的GC都是非并发的。

总体来看,在GC方面,与Dalvik相比,ART更为高效,不仅仅是GC的效率大大缩短了Pause时间,而且在内存分配上对大内存分配单独的区域,有算法在后台做内存整理,减少内存碎皮。因此在ART虚拟机下,可以避免较多的类似GC导致的卡顿问题。

以上内容来自《Android应用性能优化最佳实践》

小程序-技术共享笔记

©️2020 CSDN 皮肤主题: 猿与汪的秘密 设计师:上身试试 返回首页