2014年android内存管理了解.pptVIP

堆内存位图 在虚拟机中维护了两个对应于堆内存的位图，称为liveBits和markBits。 在对象布局中，我们看到对象最小占用8个字节。在为对象分配内存时要求必须8字节对齐。这也就是说，对象的大小会调整为8字节的倍数。比如说一个对象的实际大小是13字节，但是在分配内存的时候分配16字节。因此所有对象的起始地址一定是8字节的倍数。堆内存位图就是用来描述堆内存的，每一个bit描述8个字节，因此堆内存位图的大小是对的64分之一。对于MIUI的实现来说，这两个位图各占1M。 liveBits的作用是用来跟踪堆中以分配的内存，每分配一个对象时，对象的内存起始地址对应于位图中的位被设为1。在下一篇垃圾收集中我们会进一步的分析liveBits和markBits这两个位图的作用。 * dvmAllocObject dvmAllocObject在dalvik虚拟机中，new操作符最终对应dvmAllocObject这个C函数。下面通过伪码的形式列出dvmAllocObject的实现。Object*dvmAllocObject(ClassObject *clazz, int flags) {? ?? ???n = get object size form class object clazz? ?? ???first try: allocate n bytes from heap? ?? ???if first try failed {? ?? ?? ?? ?? ? run garbage collector without collecting soft references? ?? ?? ?? ?? ? second try: allocate n bytes from heap? ?? ???}? ?? ???if second try failed {? ?? ?? ?? ?? ? third try: grow the heap and allocate n bytes from heap? ?? ?? ?? ?? ? (注释：堆是虚拟内存，一开始并未分配所有的物理内存，只要还没有达到虚拟内存的最大值，可以通过获取更多物理内存的方式来扩展堆)? ?? ???}? ?? ???if third try failed {? ?? ?? ?? ?? ? run garbage collector with collecting soft references? ?? ?? ?? ?? ? fourth try: grow the hap and allocate n bytes from heap? ?? ???}? ?? ???if fourth try failed, return null pointer, dalvik vm will abort}可以看出，为了分配内存，虚拟机尽了最大的努力，做了四次尝试。其中进行了两次垃圾收集，第一次不收集SoftReference，第二次收集SoftReference。从中我们也可以看出垃圾收集的时机，实质上在dalvik虚拟机实现中有3个时机可以触发垃圾收集的运行：（1）程序员显式的调用System.gc()（2）内存分配失败时（3）如果分配的对象大小超过384KB，运行并发标记(concurrent mark)， * 垃圾回收 在dalvik虚拟机中，内存分配操作的流程相对比较简单直观，从一个堆中分配可用内存，分配失败时触发垃圾收集。 垃圾收集是dalvik虚拟机内存管理的核心，垃圾收集的性能在很大程度上影响了一个Java程序内存使用的效率。顾名思义，垃圾收集就是收集垃圾内存加以回收。dalvik虚拟机使用常用的Mark-Sweep算法，该算法一般分Mark阶段（标记出活动对象），Sweep阶段（回收垃圾内存）和可选的Compact阶段（减少堆中的碎片）。dalvik虚拟机的实现不进行可选的Compact阶段。 * Mark 垃圾收集的第一步是标记出活动对象，因为没有办法识别那些不可访问的对象(unreachableobjects)，因此我们只能标记出活动对象，这样所有未被标记的对象就是可以回收的垃圾 1.1 根集合(RootSet)当进行垃圾收集时，需要停止dalvik虚拟机的运行（当然，除了垃圾收集之外）。因此垃圾收集又被称作STW（stop-the-world，整个世界因我而停止）。dalvik虚拟机在运行过程中要维护一些状态信息，这些信息包括：每个线程所保存的寄存器，Java类中的静