Dalvik堆内存管理与回收

用来分配对象的堆划分为两部分：Active Heap和Zygote Heap

Android系统启动后，会有一个Zygote进程创建第一个Dalvik虚拟机，它只维护了一个堆。以后启动的所有应用程序进程都被Zygote进程fork出来，并各自持有各自的Dalvik虚拟机。

在创建应用程序的过程中，Dalvik虚拟机采用COW策略复制Zygote进程的地址空间。

COW策略：一开始的时候（未复制Zygote进程的地址空间的时候），应用程序进程和Zygote进程共享了同一个用来分配对象的堆。当Zygote进程或者应用程序进程对该堆进行写操作时，内核就会执行真正的拷贝操作，使得Zygote进程和应用程序进程分别拥有自己的一份拷贝，这就是所谓的COW。

因为copy是十分耗时的，所以必须尽量避免copy或者尽量少的copy。

为了实现这个目的，当创建第一个应用程序进程时，会将已经使用了的那部分堆内存划分为一部分，还没有使用的堆内存划分为另外一部分。前者就称为Zygote堆，后者就称为Active堆。这样只需把zygote堆中的内容复制给应用程序进程就可以了。以后无论是Zygote进程，还是应用程序进程，当它们需要分配对象的时候，都在Active堆上进行。这样就可以使得Zygote堆尽可能少地被执行写操作，因而就可以减少执行写时拷贝的操作。在Zygote堆里面分配的对象其实主要就是Zygote进程在启动过程中预加载的类、资源和对象了。这意味着这些预加载的类、资源和对象可以在Zygote进程和应用程序进程中做到长期共享。这样既能减少拷贝操作，还能减少对内存的需求。

类似于JVM，也是使用标记清除算法管理堆内存中的对象。（通过Heap Bitmap来标记标记对象有没有被引用。）

Mark-Sweep算法分为两个阶段：

Mark阶段：通过递归对象的引用，从对象的根集开始标记被引用的对象。

Sweep阶段：回收没有被标记的对象占用的内存。

所谓Heap Bitmap就是一个unsigned long数组。

Dalvik使用了两个Bitmap来描述堆的对象：Live Bitmap和Mark Bitmap。Live Bitmap用来标记上一次GC时被引用的对象，也就是没有被回收的对象；而Mark Bitmap用来标记当前GC有被引用的对象。这样只需要回收上一次被引用，当前未被引用的对象就可以了。

在Mark阶段，除了垃圾收集线程，其他线程都停止。这会使得程序卡顿，效率降低。所以必须允许在Mark阶段使垃圾回收线程和其他线程可以并发执行（Concurrent GC）。

为了实现此目的，Dalvik将Mark阶段划分为两步：

第一步，只标记根集对象（在GC过程开始的时刻，那些被全局变量，栈变量，寄存器对象引用的对象）。这个阶段只允许GC线程运行，防止这些根集对象在这个过程中再去引用其他对象。

第二步，通过这些根集对象引用关系，可以找到并标记其他正在使用的对象。这个阶段可以允许其他线程与GC线程并发执行。为了实现GC线程与其他线程并发，需要把其他线程对对象的修改记录下来，记录这些修改的数据结构被称为Card Table。

Dalvik虚拟机进行部分垃圾收集时，实际上就是只收集在Active堆上分配的对象。因此对Dalvik虚拟机来说，Card Table就是用来记录在Zygote堆上分配的对象在部收垃圾收集执行过程中对在Active堆上分配的对象的引用。

与Bitmap不同，Card Table中每个card大小为一个字节，如果与它对应的对象在第二步未被修改过，其值为clean，否则为dirty。对于被修改过的对象，在第二步结束后需要重新使用GC线程排他地对这些对象进行标记。由于这些对象不是很多所以这个过程很快，这也是分两步的原因。