在 Java 中，内存的分配是由程序完成的，而内存的释放则是由 Garbage Collecation(GC) 完成的，Java/Android 程序员不用像 C/C++ 程序员一样手动调用相关函数来管理内存的分配和释放，虽然方便了很多，但是这也就造成了内存泄漏的可能性，所以记录一下针对 Android 应用的内存泄漏的检测，处理和优化的相关内容，上篇主要会分析 Java/Android 的内存分配以及 GC 的详细分析，中篇会阐述 Android 内存泄漏的检测和内存泄漏的常见产生情景，下篇会分析一下内存优化的内容。
　　上篇：Android 性能优化之内存泄漏检测以及内存优化（上）。
　　中篇：Android 性能优化之内存泄漏检测以及内存优化（中）。
　　下篇：Android 性能优化之内存泄漏检测以及内存优化（下）。
　　转载请注明出处：http://blog.csdn.net/self_study/article/details/61919483
　　对技术感兴趣的同鞋加群544645972一起交流。

Java/Android 内存分配和回收策略分析

这里需要提到的一点是在 Android 4.4 版本之前，使用的是和 Java 一样的 Dalvik rumtime 机制，但是在 4.4 版本及以后，Android 引入了 ART 机制，ART 堆的分配与 GC 就和 Dalvik 的堆的分配与 GC 不一样了，下面会介绍到（关于 Dalvik 和 ART 的对比：Android ART运行时无缝替换Dalvik虚拟机的过程分析）。

Java/Android 内存分配策略

Java/Android 程序运行时的内存分配有三种策略，分别是静态的，栈式的和堆式的，对应的三种存储策略使用的内存空间主要分别是静态存储区（方法区）、堆区和栈区：<ul><li>静态存储区（方法区）</li>内存在程序编译的时候就已经分配好，这块内存在程序整个运行期间都存在，它主要是用来存放静态数据、全局 static 数据和常量；<li>栈区</li>在执行函数时，函数内部局部变量的存储单元都可以在栈上创建，函数执行结束时这些存储单元自动被释放，栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限；<li>堆区</li>亦称为动态内存分配，Java/Android 程序在适当的时候使用 new 关键字申请所需要大小的对象内存，然后通过 GC 决定在不需要这块对象内存的时候回收它，但是由于我们的疏忽导致该对象在不需要继续使用的之后，GC 仍然没办法回收该内存区域，这就代表发生了内存泄漏。</ul>　　堆区和栈区的区别：
　　在函数中定义的一些基本类型的变量和对象的引用变量（也就是局部变量的引用）都是在函数的栈内存分配的，当在一段代码块中定义一个变量时，Java 就在栈中为这个变量分配内存空间，当超过变量的作用域后，Java 会自动释放掉为该变量分配的内存空间，该内存空间可以立刻被重新使用；堆内存用于存放所有由 new 创建的对象（内容包括该对象其中的所有成员变量）和数组，在堆中分配的内存是由 GC 来管理的，在堆中产生了一个对象或者数组后，还可以在栈中生成一个引用指向这个堆中对象的内存区域，以后就可以通过栈中这个引用变量来访问堆中的这个引用指向的对象或者数组。下面这个图片很好的说明了它两的区别：
　　

示例图片

Java 常用垃圾回收机制

<ul><li>引用计数</li>比较古老的回收算法，原理是此对象有一个引用，即增加一个计数，删除一个引用则减少一个计数，垃圾回收时只用收集计数为 0 的对象，此算法最致命的是无法处理循环引用的问题；<li>标记-清除收集器</li>这种收集器首先遍历对象图并标记可到达的对象，然后扫描堆栈以寻找未标记对象并释放它们的内存，这种收集器一般使用单线程工作并会暂停其他线程操作，并且由于它只是清除了那些未标记的对象，而并没有对标记对象进行压缩，导致会产生大量内存碎片，从而浪费内存；<li>标记-压缩收集器</li>有时也叫标记-清除-压缩收集器，与标记-清除收集器有相同的标记阶段，但是在第二阶段则把标记对象复制到堆栈的新域中以便压缩堆栈，这种收集器也会暂停其他操作；<li>复制收集器（半空间）</li>这种收集器将堆栈分为两个域，常称为半空间，每次仅使用一半的空间，JVM 生成的新对象则放在另一半空间中，GC 运行时它把可到达对象复制到另一半空间从而压缩了堆栈，这种方法适用于短生存期的对象，持续复制长生存期的对象则导致效率降低，并且对于指定大小堆来说需要两倍大小的内存，因为任何时候都只使用其中的一半；<li>增量收集器</li>增量收集器把堆栈分为多个域，每次仅从一个域收集垃圾，也可理解为把堆栈分成一小块一小块，每次仅对某一个块进行垃圾收集，这就只会引起较小的应用程序中断时间，使得用户一般不能觉察到垃圾收集器运行；<li>分代收集器</li>复制收集器的缺点是每次收集时所有的标记对象都要被拷贝，从而导致一些生命周期很长的对象被来回拷贝多次，消耗大量的时间，而分代收集器则可解决这个问题，分代收集器把堆栈分为两个或多个域用以存放不同寿命的对象，JVM 生成的新对象一般放在其中的某个域中，过一段时间，继续存在的对象（非短命对象）将转入更长寿命的域中，分代收集器对不同的域使用不同的算法以优化性能。</ul>

Java/Android 4.4 版本之下 Dalvik 虚拟机分析

Dalvik 堆简介

这里写图片描述

Dalvik 分配内存过程分析

这里写图片描述

void* dvmMalloc(size_t size, int flags)  
{  
    void *ptr;  
  
    dvmLockHeap();  
  
    /* Try as hard as possible to allocate some memory. 
     */  
    ptr = tryMalloc(size);  
    if (ptr != NULL) {  
        /* We've got the memory. 
         */  
        if (gDvm.allocProf.enabled) {  
            Thread* self = dvmThreadSelf();  
            gDvm.allocProf.allocCount++;  
            gDvm.allocProf.allocSize += size;  
            if (self != NULL) {  
                self->allocProf.allocCount++;  
                self->allocProf.allocSize += size;  
            }  
        }  
    } else {  
        /* The allocation failed. 
         */  
  
        if (gDvm.allocProf.enabled) {  
            Thread* self = dvmThreadSelf();  
            gDvm.allocProf.failedAllocCount++;  
            gDvm.allocProf.failedAllocSize += size;  
            if (self != NULL) {  
                self->allocProf.failedAllocCount++;  
                self->allocProf.failedAllocSize += size;  
            }  
        }  
    }  
  
    dvmUnlockHeap();  
  
    if (ptr != NULL) {  
        /* 
         * If caller hasn't asked us not to track it, add it to the 
         * internal tracking list. 
         */  
        if ((flags & ALLOC_DONT_TRACK) == 0) {  
            dvmAddTrackedAlloc((Object*)ptr, NULL);  
        }  
    } else {  
        /* 
         * The allocation failed; throw an OutOfMemoryError. 
         */  
        throwOOME();  
    }  
  
    return ptr;  
}  

<li>再来具体分析一下函数 tryMalloc，tryMalloc 会调用函数 dvmHeapSourceAlloc 在 Java 堆上分配指定大小的内存，如果分配成功，那么就将分配得到的地址直接返回给调用者了，函数 dvmHeapSourceAlloc 在不改变 Java 堆当前大小的前提下进行内存分配，这是属于轻量级的内存分配动作；</li><li>如果上一步内存分配失败，这时候就需要执行一次 GC 了，不过如果 GC 线程已经在运行中，即 gDvm.gcHeap->gcRunning 的值等于 true，那么就直接调用函数 dvmWaitForConcurrentGcToComplete 等到 GC 执行完成；否则的话，就需要调用函数 gcForMalloc 来执行一次 GC 了，参数 false 表示不要回收软引用对象引用的对象；</li>

static void *tryMalloc(size_t size)  
{  
    void *ptr;  
    ......  
  
    ptr = dvmHeapSourceAlloc(size);  
    if (ptr != NULL) {  
        return ptr;  
    }  
  
    if (gDvm.gcHeap->gcRunning) {  
        ......  
        dvmWaitForConcurrentGcToComplete();  
    } else {  
        ......  
        gcForMalloc(false);  
    }  
  
    ptr = dvmHeapSourceAlloc(size);  
    if (ptr != NULL) {  
        return ptr;  
    }  
  
    ptr = dvmHeapSourceAllocAndGrow(size);  
    if (ptr != NULL) {  
        ......  
        return ptr;  
    }  
  
    gcForMalloc(true);  
    ptr = dvmHeapSourceAllocAndGrow(size);  
    if (ptr != NULL) {  
        return ptr;  
    }  
     
    ......  
  
    return NULL;  
}  

<li>GC 执行完毕后，再次调用函数 dvmHeapSourceAlloc 尝试轻量级的内存分配操作，如果分配成功，那么就将分配得到的地址直接返回给调用者了；</li><li>如果上一步内存分配失败，这时候就得考虑先将 Java 堆的当前大小设置为 Dalvik 虚拟机启动时指定的 Java 堆最大值再进行内存分配了，这是通过调用函数 dvmHeapSourceAllocAndGrow 来实现的；</li><li>如果调用函数 dvmHeapSourceAllocAndGrow 分配内存成功，则直接将分配得到的地址直接返回给调用者了；</li><li>如果上一步内存分配还是失败，这时候就得出狠招了，再次调用函数 gcForMalloc 来执行 GC，不过这次参数为 true 表示要回收软引用对象引用的对象；</li><li>上一步 GC 执行完毕，再次调用函数 dvmHeapSourceAllocAndGrow 进行内存分配，这是最后一次努力了，如果还分配内存不成功那就是 OOM 了。</li></ol>

Dalvik GC 策略分析

不同语言平台进行标记回收内存的算法是不一样的，Java 则是采用的 GC-Root 标记回收算法，在 Android 4,4 之下也是和 Java 一样的机制（Android 4.4 和之后都是使用了 ART，和dalvik GC 有不同的地方），下面这张来自 Google IO 2011 大会的图就很好的展示了Android 4.4 版本之下的回收策略：

这里写图片描述

　　上面介绍了 GC 的回收机制，那么接下来据此说一下什么是内存泄漏，从抽象定义上讲，Java/Android 平台的内存泄漏是指没有用的对象资源仍然和 GC Roots 保持可达路径，导致系统无法进行回收，具体一点讲就是，通过 GC Roots 的调用链可以遍历到这个没有被使用的对象，导致该资源无法进行释放。最常见的比如，Android 中的 Activity 中创建一个内部类 Handler 用来处理多线程的消息，而内部类会持有外部类的引用，所以该 Handler 的对象会持有 Activity 的引用，而如果这个 Handler 对象被子线程持有，子线程正在进行耗时的操作没法在短时间内执行完成，那么一系列的引用链导致 Activity 关闭之后一直无法被释放，重复地打开关闭这个 Activity 会造成这些 Activity 的对象一直在内存当中，最终达到一定程度之后会产生 OOM 异常。
　　在 Java/Android 中，虽然我们有几个函数可以访问 GC，例如运行GC的函数 System.gc()，但是根据 Java 语言规范定义，该函数不保证 JVM 的垃圾收集器一定会马上执行。因为不同的 JVM 实现者可能使用不同的算法管理 GC，通常 GC 的线程的优先级别较低。JVM 调用 GC 的策略也有很多种，有的是内存使用到达一定程度时 GC 才开始工作，也有定时执行的，有的是平缓执行GC，也有的是中断式执行GC，但通常来说我们开发者不需要关心这些。

Dalvik GC 日志分析

上面介绍到，虽然我们有几个函数可以访问 GC，但是该函数不会保证 GC 操作会立马执行，那么我怎么去监听系统的 GC 过程来实时分析当前的内存状态呢？其实很简单，Android 4.4 版本之下系统 Dalvik 每进行一次 GC 操作都会在 LogCat 中打印一条对应的日志，我们只需要去分析这条日志就可以了，日志的基本格式如下：

D/dalvikvm: <GC_Reason> <Amount_freed>, <Heap_stats>,  <Pause_time>

这段日志分为 4 个部分：<ul>
<li>首先是第一部分 GC_Reason，就是触发这次 GC 的原因，一般情况下有以下几种原因：</li><ul><li> GC_CONCURRENT </li>当我们应用程序的堆内存快要满的时候，系统会自动触发 GC 操作来释放内存；<li> GC_FOR_MALLOC </li>当我们的应用程序需要分配更多内存，可是现有内存已经不足的时候，系统会进行 GC 操作来释放内存；<li> GC_HPROF_DUMP_HEAP </li>当生成内存分析 HPROF 文件的时候，系统会进行 GC 操作，我们下面会分析一下 HPROF 文件；<li> GC_EXPLICIT </li>这种情况就是我们刚才提到过的，主动通知系统去进行GC操作，比如调用 System.gc() 方法来通知系统，或者在 DDMS 中，通过工具按钮也是可以显式地告诉系统进行 GC 操作的。</ul>
<li>第二部分 Amount_freed，表示系统通过这次 GC 操作释放了多少的内存；</li>
<li>第三部分 Heap_stats，代表当前内存的空闲比例以及使用情况（活动对象所占内存 / 当前程序总内存）；</li>
<li>第四部分 Pause_time，代表了这次 GC 操作导致应用程序暂停的时间，在 Android 2.3 版本之前 GC 操作是不能并发执行的，所以如果当系统正在 GC 的时候，应用程序只能阻塞等待 GC 结束，GC 的时间基本在几百毫秒左右，所以用户会感觉到略微明显的卡顿，体验不好，在 Android 2.3 以及之后到 4.4 版本之前，Dalvik GC 的操作改成了并发执行，也就是说 GC 的操作不会影响到主应用程序的正常运行，但是 GC 操作的开始和结束仍然会短暂的阻塞一段时间，不过时间上面就已经短到让用户无法察觉到了。</li>
</ul>

Android 4.4 及以上 ART 分析

ART 堆简介

这里写图片描述

ART 分配内存过程分析

这里写图片描述

mirror::Object* Heap::AllocObject(Thread* self, mirror::Class* c, size_t byte_count) {  
  ......  
  
  mirror::Object* obj = NULL;  
  size_t bytes_allocated = 0;  
  ......  
  
  bool large_object_allocation =  
      byte_count >= large_object_threshold_ && have_zygote_space_ && c->IsPrimitiveArray();  
  if (UNLIKELY(large_object_allocation)) {  
    obj = Allocate(self, large_object_space_, byte_count, &bytes_allocated);  
    ......  
  } else {  
    obj = Allocate(self, alloc_space_, byte_count, &bytes_allocated);  
    ......  
  }  
  
  if (LIKELY(obj != NULL)) {  
    obj->SetClass(c);  
    ......  
  
    RecordAllocation(bytes_allocated, obj);  
    ......  
  
    if (UNLIKELY(static_cast<size_t>(num_bytes_allocated_) >= concurrent_start_bytes_)) {  
      ......  
      SirtRef<mirror::Object> ref(self, obj);  
      RequestConcurrentGC(self);  
    }  
    ......  
  
    return obj;  
  } else {  
    ......  
    self->ThrowOutOfMemoryError(oss.str().c_str());  
    return NULL;  
  }  
}  

函数 Allocate 首先调用成员函数 TryToAllocate 尝试在不执行 GC 的情况下进行内存分配，如果分配失败再调用成员函数 AllocateInternalWithGc 进行带 GC 的内存分配，Allocate 是一个模板函数，不同类型的 Space 会导致调用不同重载的成员函数 TryToAllocate 进行不带 GC 的内存分配。虽然可以用来分配内存的 Space 有 Zygote Space、Allocation Space 和 Large Object Space 三个，但是前两者的类型是相同的，因此实际上只有两个不同重载版本的成员函数 TryToAllocate，它们的实现如下所示：

inline mirror::Object* Heap::TryToAllocate(Thread* self, space::AllocSpace* space, size_t alloc_size,  
                                           bool grow, size_t* bytes_allocated) {  
  if (UNLIKELY(IsOutOfMemoryOnAllocation(alloc_size, grow))) {  
    return NULL;  
  }  
  return space->Alloc(self, alloc_size, bytes_allocated);  
}  
  
// DlMallocSpace-specific version.  
inline mirror::Object* Heap::TryToAllocate(Thread* self, space::DlMallocSpace* space, size_t alloc_size,  
                                           bool grow, size_t* bytes_allocated) {  
  if (UNLIKELY(IsOutOfMemoryOnAllocation(alloc_size, grow))) {  
    return NULL;  
  }  
  if (LIKELY(!running_on_valgrind_)) {  
    return space->AllocNonvirtual(self, alloc_size, bytes_allocated);  
  } else {  
    return space->Alloc(self, alloc_size, bytes_allocated);  
  }  
} 

Heap 类两个重载版本的成员函数 TryToAllocate 的实现逻辑都几乎是相同的，首先是调用另外一个成员函数 IsOutOfMemoryOnAllocation 判断分配请求的内存后是否会超过堆的大小限制，如果超过则分配失败；否则的话再在指定的 Space 进行内存分配。函数IsOutOfMemoryOnAllocation的实现如下所示：

inline bool Heap::IsOutOfMemoryOnAllocation(size_t alloc_size, bool grow) {  
  size_t new_footprint = num_bytes_allocated_ + alloc_size;  
  if (UNLIKELY(new_footprint > max_allowed_footprint_)) {  
    if (UNLIKELY(new_footprint > growth_limit_)) {  
      return true;  
    }  
    if (!concurrent_gc_) {  
      if (!grow) {  
        return true;  
      } else {  
        max_allowed_footprint_ = new_footprint;  
      }  
    }  
  }  
  return false;  
}  

成员变量 num_bytes_allocated_ 描述的是目前已经分配出去的内存字节数，成员变量 max_allowed_footprint_ 描述的是目前堆可分配的最大内存字节数，成员变量 growth_limit_ 描述的是目前堆允许增长到的最大内存字节数，这里需要注意的一点是 max_allowed_footprint_ 是 Heap 类施加的一个限制，不会对各个 Space 实际可分配的最大内存字节数产生影响，并且各个 Space 在创建的时候，已经把自己可分配的最大内存数设置为允许使用的最大内存字节数。如果目前堆已经分配出去的内存字节数再加上请求分配的内存字节数 new_footprint 小于等于目前堆可分配的最大内存字节数 max_allowed_footprint_，那么分配出请求的内存字节数之后不会造成 OOM，因此 Heap 类的成员函数 IsOutOfMemoryOnAllocation 就返回false；另一方面，如果目前堆已经分配出去的内存字节数再加上请求分配的内存字节数 new_footprint 大于目前堆可分配的最大内存字节数 max_allowed_footprint_，并且也大于目前堆允许增长到的最大内存字节数 growth_limit_，那么分配出请求的内存字节数之后造成 OOM，因此 Heap 类的成员函数 IsOutOfMemoryOnAllocation 这时候就返回 true。
　　剩下另外一种情况，目前堆已经分配出去的内存字节数再加上请求分配的内存字节数 new_footprint 大于目前堆可分配的最大内存字节数 max_allowed_footprint_，但是小于等于目前堆允许增长到的最大内存字节数 growth_limit_，这时候就要看情况会不会出现 OOM 了：如果 ART 运行时运行在非并行 GC 的模式中，即 Heap 类的成员变量 concurrent_gc_ 等于 false，那么取决于允不允许增长堆的大小，即参数 grow 的值，如果不允许，那么 Heap 类的成员函数 IsOutOfMemoryOnAllocation 就返回 true，表示当前请求的分配会造成 OOM，如果允许，那么 Heap 类的成员函数 IsOutOfMemoryOnAllocation 就会修改目前堆可分配的最大内存字节数 max_allowed_footprint_ 并且返回 false，表示允许当前请求的分配，这意味着在非并行 GC 运行模式中，如果分配内存过程中遇到内存不足并且当前可分配内存还未达到增长上限时，要等到执行完成一次非并行 GC 后才能成功分配到内存，因为每次执行完成 GC 之后都会按照预先设置的堆目标利用率来增长堆的大小；另一方面，如果 ART 运行时运行在并行 GC 的模式中，那么只要当前堆已经分配出去的内存字节数再加上请求分配的内存字节数 new_footprint 不超过目前堆允许增长到的最大内存字节数 growth_limit_，那么就不管允不允许增长堆的大小都认为不会发生 OOM，因此 Heap 类的成员函数 IsOutOfMemoryOnAllocation 就返回 false，这意味着在并行 GC 运行模式中，在分配内存过程中遇到内存不足，并且当前可分配内存还未达到增长上限时，无需等到执行并行 GC 后就有可能成功分配到内存，因为实际执行内存分配的 Space 可分配的最大内存字节数是足够的。

ART GC 策略以及过程分析

在 Android 4.4 版本以及之后就使用了 ART 运行时，在安装的时候就将应用翻译成机器码执行，效率比起以前的 Dalvik 虚拟机更高，但是缺点就是安装之后的应用体积变大和安装的时间会变长，不过相对于优点来说，这点缺点不算什么。ART 运行时与 Dalvik 虚拟机一样，都使用了 Mark-Sweep 算法进行垃圾回收，因此它们的垃圾回收流程在总体上是一致的，但是 ART 运行时对堆的划分更加细致，因而在此基础上实现了更多样的回收策略。不同的策略有不同的回收力度，力度越大的回收策略每次回收的内存就越多，并且它们都有各自的使用情景，这样就可以使得每次执行 GC 时，可以最大限度地减少应用程序停顿：

这里写图片描述

void Heap::CollectGarbage(bool clear_soft_references) {  
  // Even if we waited for a GC we still need to do another GC since weaks allocated during the  
  // last GC will not have necessarily been cleared.  
  Thread* self = Thread::Current();  
  WaitForConcurrentGcToComplete(self);  
  CollectGarbageInternal(collector::kGcTypeFull, kGcCauseExplicit, clear_soft_references);  
}  

当我们调用 Java 层的 java.lang.System 的静态成员函数 gc 时，如果 ART 运行时支持显式 GC，那么它就会通过 JNI 调用 Heap 类的成员函数 CollectGarbageInternal 来触发一个原因为 kGcCauseExplicit 的 GC，ART 运行时默认是支持显式 GC 的，但是可以通过启动选项 -XX:+DisableExplicitGC 来关闭。所以 ART 运行时在三种情况下会触发 GC，这三种情况通过三个枚举 kGcCauseForAlloc、kGcCauseBackground 和 kGcCauseExplicitk 来描述：

// What caused the GC?  
enum GcCause {  
  // GC triggered by a failed allocation. Thread doing allocation is blocked waiting for GC before  
  // retrying allocation.  
  kGcCauseForAlloc,  
  // A background GC trying to ensure there is free memory ahead of allocations.  
  kGcCauseBackground,  
  // An explicit System.gc() call.  
  kGcCauseExplicit,  
};  

ART 运行时的所有 GC 都是以 Heap 类的成员函数 CollectGarbageInternal 为入口：

collector::GcType Heap::CollectGarbageInternal(collector::GcType gc_type, GcCause gc_cause,  
                                               bool clear_soft_references) {  
  Thread* self = Thread::Current();  
  ......  
  
  // Ensure there is only one GC at a time.  
  bool start_collect = false;  
  while (!start_collect) {  
    {  
      MutexLock mu(self, *gc_complete_lock_);  
      if (!is_gc_running_) {  
        is_gc_running_ = true;  
        start_collect = true;  
      }  
    }  
    if (!start_collect) {  
      // TODO: timinglog this.  
      WaitForConcurrentGcToComplete(self);  
      ......  
    }  
  }  
  
  ......  
  
  if (gc_type == collector::kGcTypeSticky &&  
      alloc_space_->Size() < min_alloc_space_size_for_sticky_gc_) {  
    gc_type = collector::kGcTypePartial;  
  }  
  
  ......  
  
  collector::MarkSweep* collector = NULL;  
  for (const auto& cur_collector : mark_sweep_collectors_) {  
    if (cur_collector->IsConcurrent() == concurrent_gc_ && cur_collector->GetGcType() == gc_type) {  
      collector = cur_collector;  
      break;  
    }  
  }  
  ......  
  
  collector->clear_soft_references_ = clear_soft_references;  
  collector->Run();  
  ......  
  
  {  
      MutexLock mu(self, *gc_complete_lock_);  
      is_gc_running_ = false;  
      last_gc_type_ = gc_type;  
      // Wake anyone who may have been waiting for the GC to complete.  
      gc_complete_cond_->Broadcast(self);  
  }  
  
  ......  
  
  return gc_type;  
}  

参数 gc_type 和 gc_cause 分别用来描述要执行的 GC 的类型和原因，而参数 clear_soft_references 用来描述是否要回收被软引用指向的对象，Heap 类的成员函数 CollectGarbageInternal 的执行逻辑：<ol><li>通过一个 while 循环不断地检查 Heap 类的成员变量 is_gc_running_，直到它的值等于 false 为止，这表示当前没有其它线程正在执行 GC，当它的值等于 true 时就表示其它线程正在执行 GC，这时候就要调用 Heap 类的成员函数 WaitForConcurrentGcToComplete 等待其执行完成，注意在当前 GC 执行之前，Heap 类的成员变量 is_gc_running_ 会被设置为true；</li><li>如果当前请求执行的 GC 类型为 kGcTypeSticky，但是当前 Allocation Space 的大小小于 Heap 类的成员变量 min_alloc_space_size_for_sticky_gc_ 指定的阀值，那么就改为执行类型为 kGcTypePartial；</li><li>从 Heap 类的成员变量 mark_sweep_collectors_ 指向的一个垃圾收集器列表找到一个合适的垃圾收集器来执行 GC，ART 运行时在内部创建了六个垃圾收集器，这六个垃圾收集器分为两组，一组支持并行 GC，另一组不支持；每一组都是由三个类型分别为 kGcTypeSticky、kGcTypePartial 和 kGcTypeFull 的垃垃圾收集器组成，这里说的合适的垃圾收集器是指并行性与 Heap 类的成员变量 concurrent_gc_ 一致，并且类型也与参数 gc_type 一致的垃圾收集器；</li><li>找到合适的垃圾收集器之后，就将参数 clear_soft_references 的值保存在它的成员变量 clear_soft_references_ 中，以便可以告诉它要不要回收被软引用指向的对象，然后再调用它的成员函数 Run 来执行 GC；</li><li>GC 执行完毕，将 Heap 类的成员变量 is_gc_running_ 设置为false，以表示当前 GC 已经执行完毕，下一次请求的 GC 可以执行了，此外也会将 Heap 类的成员变量 last_gc_type_ 设置为当前执行的 GC 的类型，这样下一次执行 GC 时，就可以执行另外一个不同类型的 GC，例如如果上一次执行的 GC 的类型为 kGcTypeSticky，那么接下来的两次 GC 的类型就可以设置为 kGcTypePartial 和 kGcTypeFull，这样可以使得每次都能执行有效的 GC；</li><li>通过 Heap 类的成员变量 gc_complete_cond_ 唤醒那些正在等待 GC 执行完成的线程。</li></ol>

ART GC 与 Dalvik GC 对比

�比起 Dalvik 的回收策略，ART 的 CMS（concurrent mark sweep，同步标记回收）有以下几个优点：<ul><li>阻塞的次数相比于 Dalvik 来说，从两次减少到了一次，Dalvik 第一次的阻塞大部分工作是在标记 root，而在 ART CMS 中则是被每个执行线程同步标记它们自己的 root 完成的，所以 ART 能够立马继续运行；</li><li>和 Dalvik 类似，ART GC 同样在回收执行之前有一次暂停，但是关键的不同是 Dalvik 的一些执行阶段在 ART 中是并行同步执行的，这些阶段包括标记过程、系统 weak Reference 清理过程（比如 jni weak globals 等）、重新标记非 GC Root 节点，Card 区域的提前清理。在 ART 中仍然需要阻塞的过程是扫描 Card 区域的脏数据和重新标记 GC Root，这两个操作能够降低阻塞的时间；</li><li>还有一个 ART GC 比 Dalvik 有提升的地方是 sticky CMS 提升了 GC 的吞吐量，不像正常的分代 GC 机制，sticky CMS 是不移动堆内存的，它不会给新对象分配一个特定的区域（年轻代），新分配的对象被保存在一个分配栈里面，这个栈就是一个简单的 Object 数组，这就避免了所需要移动对象的操作，也就获得了低阻塞性，但是缺点就是会增加堆的对象复杂性；</li></ul>
　　如果应用程序在前台运行时，这时候 GC 被称为 Foreground GC，同时 ART 还有一个 Background GC，顾名思义就是在后台运行的 GC，应用程序在前台运行时响应性是最重要的，因此也要求执行的 GC 是高效的，相反应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题，因此上面提到的所有 Mark-Sweep GC 适合作为 Foreground GC，而 Compacting GC（压缩 GC） 适合作为 Background GC。当从 Foreground GC 切换到 Background GC，或者从 Background GC 切换到 Foreground GC，ActivityManager 会通知发生一次 Compacting GC 的行为，这是由于 Foreground GC 和 Background GC 的底层堆空间结构是一样的，因此发生 Foreground GC 和 Background GC 切换时，需要将当前存活的对象从一个 Space 转移到另外一个 Space 上去，这个刚好就是 Semi-Space compaction 和 Homogeneous space compaction 适合干的事情。Background GC 压缩内存就能够使得内存碎片变少，从而达到缩减内存的目的，但是压缩内存的时候会暂时阻塞应用进程。 Semi-Space compaction 和 Homogeneous space compaction 有一个共同特点是都具有一个 From Space 和一个 To Space，在 GC 执行期间，在 From Space 分配的还存活的对象会被依次拷贝到 To Space 中，这样就可以达到消除内存碎片的目的。与 Semi-Space compaction 相比，Homogeneous space compaction 还多了一个 Promote Space，当一个对象是在上一次 GC 之前分配的，并且在当前 GC 中仍然是存活的，那么它就会被拷贝到 Promote Space 而不是 To Space 中，这相当于是简单地将对象划分为新生代和老生代的，即在上一次 GC 之前分配的对象属于老生代的，而在上一次 GC 之后分配的对象属于新生代的，一般来说老生代对象的存活性要比新生代的久，因此将它们拷贝到 Promote Space 中去，可以避免每次执行 Semi-Space compaction 或者 Homogeneous space compaction 时都需要对它们进行无用的处理，我们来看看这两种 Background GC 的执行过程图：
<center>

Semi-Space compaction

这里写图片描述

GC Roots 解析

�GC Roots 特指的是垃圾收集器（Garbage Collector）的对象，GC 会收集那些不是 GC Roots 且没有被 GC Roots 引用的对象，一个对象可以属于多个 Root，GC Roots 有几下种：<ul><li> Class </li>由系统类加载器（system class loader）加载的对象，这些类是不能够被回收的，他们可以以静态字段的方式持有其它对象。我们需要注意的一点就是，通过用户自定义的类加载器加载的类，除非相应的 java.lang.Class 实例以其它的某种（或多种）方式成为 Roots，否则它们并不是 Roots；<li> Thread </li>活着的线程；<li>Stack Local</li>Java 方法的 local 变量或参数；<li>JNI Local</li>JNI 方法的 local 变量或参数；<li>JNI Global</li>全局 JNI 引用；<li>Monitor Used</li>用于同步的监控对象；<li>Held by JVM</li>用于 JVM 特殊目的由 GC 保留的对象，但实际上这个与 JVM 的实现是有关的，可能已知的一些类型是系统类加载器、一些 JVM 熟悉的重要异常类、一些用于处理异常的预分配对象以及一些自定义的类加载器等，然而 JVM 并没有为这些对象提供其它的信息，因此就只有留给分析分员去确定哪些是属于 "JVM 持有" 的了。</ul>来源：https://www.yourkit.com/docs/java/help/gc_roots.jsp

ART 日志分析

�ART 的 log 不同于 Dalvik 的 log 机制，不是明确调用的情况下不会打印的 GCs 的 log 信息，GC只会在被判定为很慢时输出信息，更准确地说就是 GC 暂停的时间超过 5ms 或者 GC 执行的总时间超过 100ms。如果 app 不是处于一种停顿可察觉的状态，那么 GC 就不会被判定为执行缓慢，但是此时显式 GC 信息会被 log 出来，参考自：Investigating Your RAM Usage。

I/art: <GC_Reason> <GC_Name> <Objects_freed>(<Size_freed>) AllocSpace Objects, <Large_objects_freed>(<Large_object_size_freed>) <Heap_stats> LOS objects, <Pause_time(s)>

例如：

I/art : Explicit concurrent mark sweep GC freed 104710(7MB) AllocSpace objects, 21(416KB) LOS objects, 33% free, 25MB/38MB, paused 1.230ms total 67.216ms

<ul>
<li>GC Reason ：什么触发了GC，以及属于哪种类型的垃圾回收，可能出现的值包括<ul><li> Concurrent </li>并发 GC，不会挂起 app 线程，这种 GC 在后台线程中运行，不会阻止内存分配；<li> Alloc </li>GC 被初始化，app 在 heap 已满的时候请求分配内存，此时 GC 会在当前线程（请求分配内存的线程）执行；<li> Explicit </li>GC 被 app 显式请求，例如通过调用 System.gc() 或者 runtime.gc()，和 Dalvik 一样，ART 建议相信 GC，尽可能地避免显式调用 GC，不建议显式调用 GC 的原因是因为会阻塞当前线程并引起不必要的 CPU 周期，如果 GC 导致其它线程被抢占的话，显式 GC 还会引发 jank（jank是指第 n 帧绘制过后，本该绘制第 n+1 帧，但因为 CPU 被抢占，数据没有准备好，只好再显示一次第 n 帧，下一次绘制时显示第 n+1）；<li> NativeAlloc </li>来自 native 分配的 native memory 压力引起的 GC，比如 Bitmap 或者 RenderScript 对象；<li> CollectorTransition </li>heap 变迁引起的 GC，运行时动态切换 GC 造成的，垃圾回收器变迁过程包括从 free-list backed space 复制所有对象到 bump pointer space（反之亦然），当前垃圾回收器过渡只会在低 RAM 设备的 app 改变运行状态时发生，比如从可察觉的停顿态到非可察觉的停顿态（反之亦然）；<li> HomogeneousSpaceCompact </li>HomogeneousSpaceCompact 指的是 free-list space 空间的压缩，经常在 app 变成不可察觉的停顿态时发生，这样做的主要原因是减少 RAM 占用并整理 heap 碎片；<li> DisableMovingGc </li>不是一个真正的 GC 原因，正在整理碎片的 GC 被 GetPrimitiveArrayCritical 阻塞，一般来说因为 GetPrimitiveArrayCritical 会限制垃圾回收器内存移动，强烈建议不要使用；<li> HeapTrim </li>不是一个真正的 GC 原因，仅仅是一个收集器被阻塞直到堆压缩完成的记录。</ul></li>
<li> GC Name：ART有几种不同的GC<ul><li>Concurrent mark sweep (CMS)</li>全堆垃圾收集器，负责收集释放除 image space（上面 ART 堆的图片中对应区域）外的所有空间；<li>Concurrent partial mark sweep</li>差不多是全堆垃圾收集器，负责收集除 image space 和 zygote space 外的所有空间；<li>Concurrent sticky mark sweep</li>分代垃圾收集器，只负责释放从上次 GC 到现在分配的对象，该 GC 比全堆和部分标记清除执行得更频繁，因为它更快而且停顿更短；<li>Marksweep + semispace</li>非同步的，堆拷贝压缩和 HomogeneousSpaceCompaction 同时执行。</ul></li>
<li>Objects freed</li>本次 GC 从非大对象空间（non large object space）回收的对象数目。
<li>Size freed</li>本次 GC 从非大对象空间回收的字节数。
<li>Large objects freed</li>本次 GC 从大对象空间里回收的对象数目。
<li>Large object size freed</li>本次GC从大对象空间里回收的字节数。
<li>Heap stats</li>可用空间所占的百分比和 [已使用内存大小] / [ heap 总大小]。
<li>Pause times</li>一般情况下，GC 运行时停顿次数和被修改的对象引用数成比例，目前 ART CMS GC 只会在 GC 结束的时停顿一次，GC 过渡会有一个长停顿，是 GC 时耗的主要因素。
</ul>

Java/Android 引用解析

�GC 过程是和对象引用的类型是严重相关的，我们在平时接触到的一般有三种引用类型，强引用、软引用、弱引用和虚引用：

在 Java/Android 开发中，为了防止内存溢出，在处理一些占内存大而且生命周期比较长对象的时候，可以尽量应用软引用和弱引用，软/弱引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收器回收，Java 虚拟机就会把这个软引用加入到与之关联的引用队列中，利用这个队列可以得知被回收的软/弱引用的对象列表，从而为缓冲器清除已失效的软/弱引用。

Android 内存泄漏和优化

�具体的请看中篇：Android 性能优化之内存泄漏检测以及内存优化（中）和下篇：Android 性能优化之内存泄漏检测以及内存优化（下）。

引用

http://blog.csdn.net/luoshengyang/article/details/42555483
http://blog.csdn.net/luoshengyang/article/details/41688319
http://blog.csdn.net/luoshengyang/article/details/42492621
http://blog.csdn.net/luoshengyang/article/details/41338251
http://blog.csdn.net/luoshengyang/article/details/41581063
https://mp.weixin.qq.com/s?__biz=MzA4MzEwOTkyMQ==&mid=2667377215&idx=1&sn=26e3e9ec5f4cf3e7ed1e90a0790cc071&chksm=84f32371b384aa67166a3ff60e3f8ffdfbeed17b4c8b46b538d5a3eec524c9d0bcac33951a1a&scene=0&key=c2240201df732cf062d22d3cf95164740442d817864520af90bb0e71fa51102f2e91475a4f597ec20653c59d305c8a3e518d3f575d419dfcf8fb63a776e0d9fa6d3a9a6a52e84fedf3f467fe4af1ba8b&ascene=0&uin=Mjg5MDI3NjQ2Mg%3D%3D&devicetype=iMac+MacBookPro11%2C4+OSX+OSX+10.12.3+build(16D32)&version=12010310&nettype=WIFI&fontScale=100&pass_ticket=Upl17Ws6QQsmZSia%2F%2B0xkZs9DYxAJBQicqh8rcaxYUjcu3ztlJUPxYrQKML%2BUtuf
http://geek.csdn.net/news/detail/127226
http://www.jianshu.com/p/216b03c22bb8
https://zhuanlan.zhihu.com/p/25213586
https://joyrun.github.io/2016/08/08/AndroidMemoryLeak/
http://www.cnblogs.com/larack/p/6071209.html
https://source.android.com/devices/tech/dalvik/gc-debug.html
http://blog.csdn.net/high2011/article/details/53138202
http://gityuan.com/2015/10/03/Android-GC/
http://www.ayqy.net/blog/android-gc-log%E8%A7%A3%E8%AF%BB/
https://developer.android.com/studio/profile/investigate-ram.html