💎一站式轻松地调用各大LLM模型接口,支持GPT4、智谱、星火、月之暗面及文生图 广告
[原文出处--------------ART运行时垃圾收集机制简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/42072975) 为了学习ART运行时的垃圾收集机制,我们先把Dalvik虚拟机的垃圾收集机制研究了一遍。这是因为两者都使用到了Mark-Sweep算法,因此它们在概念上有很多一致的地方。然而在实现上,Dalvik虚拟机的垃圾收集机制要简单一些。这样我们就可以先从简单的Dalvik虚拟机垃圾收集机制入手,然后再逐步深入地学习复杂的ART运行时垃圾收集机制。本文就对ART运行时垃圾收集机制进行简要介绍和制定学习计划。 与Dalvik虚拟机垃圾收集机制简要介绍和学习计划一文介绍的Dalvik虚拟机垃圾收集机制一样,ART运行时垃圾收集机制也涉及到类似于Zygote堆、Active堆、Card Table、Heap Bitmap和Mark Stack等概念,如图1所示: ![](https://box.kancloud.cn/004d9af976272de89c6c8af969094129_833x719.png) 图1 ART运行时垃圾收集机制的基本概念 从图1可以看到,ART运行时堆划分为四个空间,分别是Image Space、Zygote Space、Allocation Space和Large Object Space。其中,Image Space、Zygote Space、Allocation Space是在地址上连续的空间,称为Continuous Space,而Large Object Space是一些离散地址的集合,用来分配一些大对象,称为Discontinuous Space。 在Image Space和Zygote Space之间,隔着一段用来映射system@framework@boot.art@classes.oat文件的内存。从前面[Android运行时ART加载OAT文件的过程分析](http://blog.csdn.net/luoshengyang/article/details/39307813)一文可以知道,system@framework@boot.art@classes.oat是一个OAT文件,它是由在系统启动类路径中的所有DEX文件翻译得到的,而Image Space空间就包含了那些需要预加载的系统类对象。这意味着需要预加载的类对象是在生成system@framework@boot.art@classes.oat这个OAT文件的时候创建并且保存在文件system@framework@boot.art@classes.dex中,以后只要系统启动类路径中的DEX文件不发生变化(即不发生更新升级),那么以后每次系统启动只需要将文件system@framework@boot.art@classes.dex直接映射到内存即可,省去了创建各个类对象的时间。之前使用Dalvik虚拟机作为应用程序运行时时,每次系统启动时,都需要为那些预加载的类创建类对象。因此,虽然ART运行时第一次启动时会比较慢,但是以后启动实际上会更快。 由于system@framework@boot.art@classes.dex文件保存的是一些预先创建的对象,并且这些对象之间可能会互相引用,因此我们必须保证system@framework@boot.art@classes.dex文件每次加载到内存的地址都是固定的。这个固定的地址保存在system@framework@boot.art@classes.dex文件开头的一个Image Header中。此外,system@framework@boot.art@classes.dex文件也依赖于system@framework@boot.art@classes.oat文件,因此也会将后者固定加载到Image Space的末尾。 Zygote Space和Allocation Space与Dalvik虚拟机垃圾收集机制中的Zygote堆和Active堆的作用是一样的。Zygote Space在Zygote进程和应用程序进程之间共享的,而Allocation Space则是每个进程独占的。同样的,Zygote进程一开始只有一个Image Space和一个Zygote Space。在Zygote进程fork第一个子进程之前,就会把Zygote Space一分为二,原来的已经被使用的那部分堆还叫Zygote Space,而未使用的那部分堆就叫Allocation Space。以后的对象都在Allocation Space上分配。 通过上述这种方式,就可以使得Image Space和Zygote Space在Zygote进程和应用程序进程之间进行共享,而Allocation Space就每个进程都独立地拥有一份。注意,虽然Image Space和Zygote Space都是在Zygote进程和应用程序进程之间进行共享,但是前者的对象只创建一次,而后者的对象需要在系统每次启动时根据运行情况都重新创建一遍。 为了验证上面的分析,我们在某一次系统启动时,查看Settings.apk进程的地址空间,如图2所示: ![](https://box.kancloud.cn/86a433990d5960d8befa55dd3729668b_1090x286.png) 图2 Settings.apk的地址空间 其中,地址空间0x60000000-0x60a94000对应的就是Image Space,它映射的是system@framework@boot.art@classes.dex文件,固定映射在地址0x60000000上。紧跟着的地址空间0x60a94000-0x64591000映射的是system@framework@boot.art@classes.oat文件。再接下来就是Zygote Space和Allocation Space,分别映射在地址空间0x64591000-0x646e7000和0x646e7000-0x6754e000上。并且都是匿名共享内存块。另外,通过翻译Settings.apk里面的classes.dex文件得到的OAT文件system@priv-app@Settings.apk@classes.dex映射在地址空间0xaf29b000-0xaf654000上。 与Dalivk虚拟机类似,ART运行时也使用一个Heap对象来描述堆,它的实现如图3所示: ![](ART运行时堆描述类Heap的实现) 图3 ART运行时堆描述类Heap的实现 Heap类包含了以下重要成员变量描述ART运行时的堆,它们的作用如下所述: 1. mark_sweep_collectors_: 一个std::vector<collector::MarkSweep*>向量,保存了六种Mark-Sweep垃圾收集器。 2. continuous_spaces_: 一个std::vector<space::ContinuousSpace*>向量,保存了图1所示的三个在地址空间上连续的Image Space、Zygote Space和Allocation Space。 3. concurrent_gc_: 一个bool变量,描述是否支持并行GC,可以通过ART运行时启动选项-Xgc来指定。 4. parallel_gc_threads_: 一个size_t变量,指定在GC暂停阶段用来同时执行GC任务的线程数,可以通过ART运行时启动选项-XX:ParallelGCThreads指定。如果没有指定,它的值就等于CPU核心数减1。这里之所以要减1是因为parallel_gc_threads_描述的实际上是除了当前GC线程之外的其它也用于GC任务的线程的个数。 5. conc_gc_threads_: 一个size_t变量,指定非GC暂停阶段用来同时执行GC任务的线程数,可以通过ART运行时启动选项-XX:ConcGCThreads来指定。 6. discontinuous_spaces_: 一个std::vector<space::DiscontinuousSpace*>向量,保存了图1所示的在地址空间上不连续的Large Object Space。 7. alloc_space_: 一个space::DlMallocSpace指针,指向一个space::DlMallocSpace对象,该对象描述的是图1所示的Allocation Space。 8. large_object_space_: 一个space::LargeObjectSpace指针,指向一个space::LargeObjectSpace对象,该对象描述的是图1所示的Large Object Space。 9. card_table_: 一个UniquePtr<accounting::CardTable>指针,指向一个accounting::CardTable对象,该对象描述的是图1所示的Card Table。 10. image_mod_union_table_: 一个UniquePtr<accounting::ModUnionTable>指针,指向一个accounting::ModUnionTable对象,该对象描述的是图1所示的位于上方的Mod Union Table对象,用来记录在GC并行阶段在Image Space上分配的对象对在Zygote Space和Allocation Space上分配的对象的引用。 11. zygote_mod_union_table_: 一个UniquePtr<accounting::ModUnionTable>指针,指向一个accounting::ModUnionTable对象,该对象描述的是图1所示的位于下方的Mod Union Table,用来记录在GC并行阶段在Zygote Space上分配的对象对在Allocation Space上分配的对象的引用。 12. mark_stack_: 一个UniquePtr<accounting::ObjectStack>指针,指向一个accounting::ObjectStack对象,该对象描述的是图1所示的Mark Stack,用来在GC过程中实现递归对象标记。 13. allocation_stack_: 一个UniquePtr<accounting::ObjectStack>指针,指向一个accounting::ObjectStack对象,该对象描述的是图1所示的Allocation Stack,用来记录上一次GC后分配的对象,用来实现类型为Sticky的Mark Sweep Collector。 14. live_stack_: 一个UniquePtr<accounting::ObjectStack>指针,指向一个accounting::ObjectStack对象,该对象描述的是图1所示的Live Stack,配合allocation_stack_一起使用,用来实现类型为Sticky的Mark Sweep Collector。 15. mark_bitmap_: 一个UniquePtr<accounting::HeapBitmap>指针,指向一个accounting::HeapBitmap对象,该对象描述的是图1所示的Mark Bitmap,与Dalvik虚拟机的Mark Bitmap作用是一样的,用来标记当前GC之后还存活的对象。 16. live_bitmap_: 一个UniquePtr<accounting::HeapBitmap>指针,指向一个accounting::HeapBitmap对象,该对象描述的是图1所示的Live Bitmap,与Dalvik虚拟机的Live Bitmap作用是一样的,用来标记上一次GC之后还存活的对象。 除了上述的16个成员变量,Heap类还定义了以下三个垃圾收集接口: 1. CollectGarbage: 用来执行显式GC,例如用实现System.gc接口。 2. ConcurrentGC: 用来执行并行GC,只能被ART运行时内部的GC守护线程调用。 3. CollectGarbageInternal: ART运行时内部调用的GC接口,可以执行各种类型的GC。 上面我们提到,Heap类的成员变量mark_sweep_collectors_保存了ART运行时内部使用的六种垃圾收集器,这六种垃圾收集器分为两组。其中一组是支持并行GC的,另一组是不支持并行GC的。每一组都由MarkSweep、PartialMarkSweep和StickyMarkSweep三种类型的垃圾收集器组成。它们的类关系如图4所示: ![](https://box.kancloud.cn/e318278031fb69375e1dd6d486442f5b_729x680.jpg) 图4 ART运行时的垃圾收集器 StickyMarkSweep继承于PartialMarkSweep,PartialMarkSweep又继承于MarkSweep、而MarkSweep又继承于GarbageCollector。因此,我们可以推断出,GarbageCollector定义了垃圾收集器接口,而MarkSweep、PartialMarkSweep和StickyMarkSweep通过重定某些接口来实现不同类型的垃圾收集器。 在GarbageCollector中,有一个成员变量heap_,指向的是ART运行时堆,同时定义了两个public成员函数IsConcurrent和GetGcType。前者用来获得一个垃圾收集器是否支持并行GC,后者用来获得垃圾收集器类型 。 垃圾收集器类型通过枚举类型GcType来描述,它的定义如下所示: ~~~ // The type of collection to be performed. The ordering of the enum matters, it is used to // determine which GCs are run first. enum GcType { // Placeholder for when no GC has been performed. kGcTypeNone, // Sticky mark bits GC that attempts to only free objects allocated since the last GC. kGcTypeSticky, // Partial GC that marks the application heap but not the Zygote. kGcTypePartial, // Full GC that marks and frees in both the application and Zygote heap. kGcTypeFull, // Number of different GC types. kGcTypeMax, }; ~~~ 这个枚举类型定义在文件t/runtime/gc/collector/gc_type.h中。 其中,kGcTypeNone是一个占位符,kGcTypeMax描述的是垃圾收集器类型个数。kGcTypeSticky指的就是StickyMarkSweep类型的垃圾收集器,用来收集上次GC以来分配的对象。kGcTypePartial指的就是PartialMarkSweep类型的垃圾收集器,用来收集在Allocation Space上分配的对象。kGcTypeFull指的就是MarkSweep类型的垃圾收集器,用来收集在Zygote Space和Allocation Space上分配的对象。 此外,GarbageCollector通过定义以下五个虚函数描述GC的各个阶段: 1. InitializePhase: 用来实现GC的初始化阶段,用来初始化垃圾收集器内部的状态。 2. MarkingPhase: 用来实现GC的标记阶段,该阶段有可能是并行的,也有可能不是并行。 3. HandleDirtyObjectsPhase: 用来实现并行GC的Dirty Object标记,也就是递归标记那些在并行标记对象阶段中被修改的对象。 4. ReclaimPhase: 用来实现GC的回收阶段。 5. FinishPhase: 用来实现GC的结束阶段。 MarkSweep类通过重写上述五个虚函数实现自己的垃圾收集过程,同时,它又通过定义以下三个虚函数来让子类PartialMarkSweep和StickyMarkSweep实现特定的垃圾收集器: 1. MarkReachableObjects: 用来递归标记从根集对象引用的其它对象。 2. BindBitmap: 用来指定垃圾收集范围。 3. Sweep: 用来回收垃圾对象。 其中,MarkSweep类通过自己实现的成员函数BindBitmap将垃圾收集范围指定为Zygote和Allocation空间,而PartialMarkSweep和StickyMarkSweep类通过重写成员函数BindBitmap将垃圾收集范围指定为Allocation空间和上次GC后所分配的对象。此外,StickyMarkSweep类还通过重定成员函数MarkReachableObjects和Sweep将对象标记和回收限制为上次GC后所分配的对象。 上面我们也提到了ART运行时将堆划分为连续空间和不连续空间两种类型,每一种类型又分别有不同的实现。这些实现的类关系如图5所示: ![](https://box.kancloud.cn/528eabce7f3d9c48ffa3ae7010fd560a_1324x1114.jpg) 图5. ART运行时各种堆空间的关系图 首先看最下面的三个类ImageSpace、DlMallocSpace和LargeObjectMapSpace。其中,ImageSpace描述的是Image Space,DlMallocSpace描述的是Zygote Space和Allocation Space,LargeObjectMapSpace描述的是Large Object Space。它们都有一个共同的基类Space。 Space类有一个类型为GcRetentionPolicy的成员变量gc_retention_policy_,用来描述一个Space的回收策略。GcRetentionPolicy是一个枚举类型,它的定义如下所示: ~~~ // See Space::GetGcRetentionPolicy. enum GcRetentionPolicy { // Objects are retained forever with this policy for a space. kGcRetentionPolicyNeverCollect, // Every GC cycle will attempt to collect objects in this space. kGcRetentionPolicyAlwaysCollect, // Objects will be considered for collection only in "full" GC cycles, ie faster partial // collections won't scan these areas such as the Zygote. kGcRetentionPolicyFullCollect, }; ~~~ 这个枚举类型定义在文件art/runtime/gc/space/space.h中。 kGcRetentionPolicyNeverCollect表示永远不会进行垃圾回收的Space,例如Image Space。kGcRetentionPolicyAlwaysCollect表示每一次GC都会尝试回收垃圾的Space,例如Allocation Space。kGcRetentionPolicyFullCollect表示只有执行类型为kGcTypeFull的GC才会进行垃圾回收的Space,例如Zygote Space。通过Space类的成员函数GetGcRetentionPolicy可以获得一个Space的回收策略。 一个Space除了具有回收策略之外,还具有Space Type,通过枚举类型SpaceType来描述。枚举类型SpaceType的定义如下所示: ~~~ enum SpaceType { kSpaceTypeImageSpace, kSpaceTypeAllocSpace, kSpaceTypeZygoteSpace, kSpaceTypeLargeObjectSpace, }; ~~~ 这个枚举类型定义在文件art/runtime/gc/space/space.h中。 kSpaceTypeImageSpace、kSpaceTypeAllocSpace、kSpaceTypeZygoteSpace和kSpaceTypeLargeObjectSpace描述的就分别是Image Space、Allocation Space、Zygote Space和Large Object Space。通过Space类的成员函数GetType可以获得一个Space的Type。此外,Space类还提供了IsImageSpace、IsDlMallocSpace、IsZygoteSpace和IsLargeObjectSpace四个辅助成员函数来方便判断一个Space的类型。 前面我们提到,Space划分Continuous和Discontinuous两种,其实还可以划分为Allocable和Non-Allocable两种。例如,Image Space是不能分配新对象的,而Zygote Space、Allocation Space和Large Object Space是可以分配对象。对于可分配新对象的Space,ART运行时定义了一个基类AllocSpace,它的定义以下几个重要的接口来描述一个可分配新对象的Space,如下所示: 1. GetBytesAllocated: 获得当前已经分配的字节数。 2. GetObjectsAllocated: 获得当前已经分配的对象数。 3. GetTotalBytesAllocated: 获得Space自创建以来所分配的字节数。 4. GetTotalObjectsAllocated: 获得Space自创建以来所分配的对象数。 5. Alloc: 在Space上分配一个指定大小的对象。 6. AllocationSize: 获得一个对象占据的内存块大小。 7. Free: 释放一个对象占据的内存块。 8. FreeList: 批量释放一系列对象占据的内存块。 Continuous Space和Discontinuous Space分别使用类ContinuousSpace和DiscontinuousSpace来描述,它们都是从类Space继承下来的。 ContinuousSpace类有两个成员变量begin_和end_,用来描述一个Continuous Space内部所使用的内存块的开始和结束地址。此外,ContinuousSpace类还定义了以下几个重要接口来获得一个Continuous Space的相关信息,如下所示: 1. Begin: 获得Space的起始地址。 2. End: 获得Space的结束地址。 3. Size: 获得Space的大小。 4. GetLiveBitmap: 获得Space的Live Bitmap。 5. GetMarkBitmap: 获得Space的Mark Bitmap。 由于Discontinuous Space在地址空间上是不连续的,因此它不像Continuous Space一样,可以使用类似begin_和end_的成员变量来确定Space内部使用的内存块。DiscontinuousSpace类在内部使用两个SpaceSetMap容器live_objects_和mark_objects_来描述已经分配对象集合和在GC过程中被标记的对象集合。此外,DiscontinuousSpace类还定义了以下两个接口来获得这两个对象集合,如下所示: 1. GetLiveObjects: 获得当前分配的对象集合。 2. GetMarkObjects: 获得在当前GC过程被标记的对象集合。 Continuous Space内部使用的内存块都是通过内存映射得到的,不过这块内存有可能是通过不同方式映射得到的。例如,Image Space内部使用的内存块是通过内存映射Image文件得到的,而Zygote Space和Allocation Space内部使用的内存块是通过内存映射匿名共享内存得到。通过内存映射得到的Space使用类MemMapSpace来描述,它继承于ContinousSpace。MemMapSpace类有一个成员变量mem_map_,类型是UniquePtr<MemMap>,指向一块由一个MemMap对象描述的内存块,可以通过成员函数Capacity来获得该内存块的大小。 从图5可以看到,Image Space是通过ImageSpace类来描述,它继承于MemMapSpace类。前面我们提到,Image Space是从一个Image文件获得的,就是图1所示的boot.art@classes.dex文件,从[Android运行时ART加载OAT文件的过程分析](http://blog.csdn.net/luoshengyang/article/details/39307813)一文又可以知道,Image文件关联有一个OAT文件,就是图1所示的boot.art@classes.oat文件。因此,在ImageSpace类内部,有一个成员变量oat_file_,用来描述与Image Space关联的OAT文件。此外。在ImageSpace类内部,还有一个类型为UniquePtr<accounting::SpaceBitmap>的成员变量live_bitmap_,用来标记Imape Space的存活对象。由于Image Space是不会进行新对象分配和垃圾回收的,因此它不像其它Space一样,还有另外一个Mark Bitmap。不过Space要求其子类要有一个Live Bitmap和一个Mark Bitmap,于是,ImageSpace就将内部的live_bitmap_同时作为Live Bitmap和Mark Bitmap来使用。 ImageSpace还通过定义以下几个接口来获得Image Space的相关信息,如下所示: 1. GetType: 重写了父类Space的成员函数GetType,返回固定为kSpaceTypeImageSpace,表示这是一个Image Space。 2. GetLiveBitmap: 获得Image Space的Live Bitmap。 3. GetMarkBitmap: 获得Image Space的Mark Bitmap。 4. Create: 一个静态成员函数,根据指定的Image文件创建一个Image Space。 Zygote Space和Allocation Space都是通过类DlMallocSpace来描述。虽然Zygote Space和Allocation Space内部使用的内存块都是通过内存映射得到的,不过在使用它们的时候,是通过C库提供的内存管理接口来使用的,因此这里就将它们的名字命名为DlMalloc,这也是DlMallocSpace的由来。由于DlMallocSpace还是可以分配新对象的,因此在图5中,我们看到它除了继承于MemMapSpace类之外,还继承于AllocSpace。 DlMallocSpace定义了以下几个重要成员变量来描述内部状态,如下所示: 1. mspace_: 和Dalvik虚拟机一样,ART运行时也是将Zygote Space和Allocation Space使用的匿名共享内存块封装成一个mspace对象,以便可以使用C库提供的内存管理接口来在上面分配和释放内存。 2. live_bitmap_: 指向一个SpaceBitmap,用来记录上次GC后存活对象。 3. mark_bitmap_: 指向一个SpaceBitmap,用来记录当前GC被标记的对象。 4. num_bytes_allocated_: 记录当前已经分配的内存字节数。 5. num_objects_allocated_: 记录当前已经分配的对象数。 6. total_bytes_allocated_: 记录从Space创建以来所分配的内存字节数。 7. total_objects_allocated_: 记录从Space创建以来所分配的对象数。 DlMallocSpace还新定义或者重写了父类的成员函数,如下所示: 1. GetType: 重写了父类Space的成员函数GetType,返回固定为SpaceTypeZygoteSpace或者kSpaceTypeAllocSpace,表示这是一个Zygote Space或者Allocation Space。 2. Create: 一个静态成员函数,用来创建一个Zygote Space或者Allocation Space。 3. GetBytesAllocated: 重写了父类AllocSpace的成员函数GetBytesAllocated。 4. GetObjectsAllocated: 重写了父类AllocSpace的成员函数GetObjectsAllocated。 5. GetTotalBytesAllocated: 重写了父类AllocSpace的成员函数GetTotalBytesAllocated。 6. GetTotalObjectsAllocated: 重写了父类AllocSpace的成员函数GetTotalObjectsAllocated。 7. Alloc: 重写了父类AllocSpace的成员函数Alloc。 8. AllocationSize: 重写了父类AllocSpace的成员函数AllocationSize。 9. Free: 重写了父类AllocSpace的成员函数Free。 10. FreeList: 重写了父类AllocSpace的成员函数FreeList。 11. Capacity: 重写了父类MemMapSpace的成员函数Capacity。 现在再来看最后一种Space -- Large Object Space。ART运行时提供了两种Large Object Space实现。其中一种实现和Continuous Space的实现类似,预先分配好一块大的内存空间,然后再在上面为对象分配内存块。不过这种方式实现的Large Object Space不像Continuous Space通过C库的内块管理接口来分配和释放内存,而是自己维护一个Free List。每次为对象分配内存时,都是从这个Free List找到合适的空闲的内存块来分配。释放内存的时候,也是将要释放的内存添加到该Free List去。 另外一种Large Object Space实现是每次为对象分配内存时,都单独为其映射一新的内存。也就是说,为每一个对象分配的内存块都是相互独立的。这种实现方式相比上面介绍的Free List实现方式,也更简单一些。在Android 4.4中,ART运行时使用的是后一种实现方式,因此我们这里也主要是介绍这种实现。 为每一对象映射一块独立的内存块的Large Object Space实现称为LargeObjectMapSpace,它与Free List方式的实现都是继承于类LargeObjectSpace。LargeObjectSpace又分别继承了DiscontinuousSpace和AllocSpace。因此,我们就可以知道,LargeObjectMapSpace描述的是一个在地址空间上不连续的Large Object Space。 LargeObjectSpace定义了以下重要成员变量描述内部状态,如下所示: 1. num_bytes_allocated_: 记录当前已经分配的内存字节数。 2. num_objects_allocated_: 记录当前已经分配的对象数。 3. total_bytes_allocated_: 记录从Space创建以来所分配的内存字节数。 4. total_objects_allocated_: 记录从Space创建以来所分配的对象数。 LargeObjectSpace还重写了父类AllocSpace的以下成员函数: 1. GetType: 重写了父类Space的成员函数GetType,返回固定为kSpaceTypeLargeObjectSpace,表示这是一个Large Object Space。 2. GetBytesAllocated: 重写了父类AllocSpace的成员函数GetBytesAllocated。 3. GetObjectsAllocated: 重写了父类AllocSpace的成员函数GetObjectsAllocated。 4. GetTotalBytesAllocated: 重写了父类AllocSpace的成员函数GetTotalBytesAllocated。 5. GetTotalObjectsAllocated: 重写了父类AllocSpace的成员函数GetTotalObjectsAllocated。 6. FreeList: 重写了父类AllocSpace的成员函数FreeList。 LargeObjectMapSpace继承于LargeObjectSpace,它内部有一个成员变量large_objects_,指向一个std::vector<mirror::Object*, accounting::GCAllocator<mirror::Object*> >向量,里面保存的就是为每一个对象独立映射的内存块。 此外,LargeObjectMapSpace还新定义或者重写了父类AllocSpace的以下成员变量: 1. Create: 一个静态成员函数,用来创建一个LargeObjectMapSpace。 2. Alloc: 重写了父类AllocSpace的成员函数Alloc。 3. AllocationSize: 重写了父类AllocSpace的成员函数AllocationSize。 4. Free: 重写了父类AllocSpace的成员函数Free。 除了Garbage Collector和Space,ART运行时垃圾收集机制比Dalvik垃圾收集机制还多了一个称Mod Union Table的概念。Mod Union Table是与Card Table配合使用的,用来记录在一次GC过程中,记录不会被回收的Space的对象对会被回收的Space的引用。例如,Image Space的对象对Zygote Space和Allocation Space的对象的引用,以及Zygote Space的对象对Allocation Space的对象的引用。 ART运行时定义了一个ModUnionTable基类以及一系列的子类,用来记录不同Space的对象对特定Space的对象的引用,它们的关系如图6所示: ![](https://box.kancloud.cn/7ec40250c0c49b44b76da56e1d685253_785x498.jpg) 图6 ART运行时的Mod Union Table实现 ModUnionTable类有一个成员变量heap_,指向ART运行时堆,可以通过成员函数GetHeap来获得。 在GC标记阶段,Card Table和Mod Union Table分三步处理。第一步是调用ModUnionTable类的成员函数ClearCards清理Card Table里面的Dirty Card,并且将这些Dirty Card记录在Mod Union Table中。第二步是调用ModUnionTable类的成员函数Update将遍历记录在Mod Union Table里面的Drity Card,并且找到对应的被修改对象,然后将被修改对象引用的其它对象记录起来。第三步是调用ModUnionTable类的成员函数MarkReferences标记前面第二步那些被被修改对象引用的其它对象。通过这种方式,就可以使用Card Table可以在标记阶段重复使用,即在执行第二步之前,重复执行第一步,最后通过Mod Union Table将所有被被修改对象引用的其它对象收集起来统一进行标记,避免对相同对象进行重复标记。 上面说到,Mod Union Table的作用就使得Card Table可以重复使用,前提是Mod Union Table将每一次清理Card Table之前,将之前已经是Dirty的Card缓存起来。因此,ModUnionTableCardCache类继承ModUnionTable类的时候,定义了一个类型为CardSet的成员变量cleared_cards_,就是用来缓存Dirty Card的,并且它重写了父类ModUnionTable的成员函数ClearCards、Update和MarkReferences来实现自己的DIrty Card缓存策略。 另外一个继承于ModUnionTable的子类ModUnionTableReferenceCache,不单会将Dirty Card缓存起来保存在类型同样为CardSet的成员变量cleared_cards_中,而且还将与这些Dirty Card对应的被引用对象也缓存起来保存在成员变量references_指向的一个SafeMap中。同样的,ModUnionTableReferenceCache重写了父类ModUnionTable的成员函数ClearCards、Update和MarkReferences来实现自己的Dirty Card缓存策略。此外,ModUnionTableReferenceCache还提供了一个AddReference接口,用来决定哪些被引用对象需要缓存。 ModUnionTableReferenceCache类并不是直接使用的,它也是作为基类使用。ART运行时提供了两个子类ModUnionTableToZygoteAllocspace和ModUnionTableToAllocspce,它们都继承于ModUnionTableReferenceCache类。从名字我们可以大致推断出,ModUnionTableToZygoteAllocspace类是用来记录位于Zygote Space和Allocation Space的被引用对象的,而ModUnionTableToAllocspace是用来记录位于Allocation Space的被引用对象的,也就是对应于前面图1所示的两个Mod Union Table。不过ART运行时实际上是使用ModUnionTableCardCache来记录位于Allocation Space的被引用对象的。在后面的文章中,我们就可以看到这一点。 至此,ART运行时垃圾收集机制涉及到的基础概念我们就介绍完毕。要做到完全理解这些概念,除了要熟悉[Dalvik虚拟机垃圾收集机制简要介绍和学习计划](http://blog.csdn.net/luoshengyang/article/details/41338251)这一系列文章分析Dalvik虚拟机垃圾收集机制之外,还需要继续从以下情景来进一步分析ART运行时垃圾机制: 1. [ART运行时堆的创建过程](http://blog.csdn.net/luoshengyang/article/details/42379729)。 2. [ART运行时的对象分配过程](http://blog.csdn.net/luoshengyang/article/details/42492621)。 3. [ART运行时的垃圾收集过程](http://blog.csdn.net/luoshengyang/article/details/42555483)。 按照这三个情景学习ART运行时的垃圾收集机制之后,我们就会对上面涉及的概念有一个清晰的认识了。