[序言]
GC是Java对内存回收机制，了解GC，应该从了解GC的概念、内存分配、识别哪些内存需要回收和回收方式几个方面开始~
[GC]
垃圾回收器跟踪并回收托管内存中分配的对象，定期执行垃圾回收以回收分配给没有有效引用的对象的内存。当使用可用内存不能满足内存请求时，GC会自动进行。
[内存分配]
栈的内存管理是顺序分配的，而且定长，不存在内存回收问题；而 堆 则是为Java对象的实例随机分配内存，不定长度，所以存在内存分配和回收的问题。
Java虚拟机是先一次性分配一块较大的空间，然后每次new时都在该空间上进行分配和释放，减少了系统调用的次数，节省了一定的开销，这有点类似于
内存池的概念；二是有了这块空间过后，如何进行分配和回收就跟GC机制有关了。
[检查识别需要回收内存]
引用计数法
给一个对象添加引用计数器，每当有个地方引用它，计数器就加1；引用失效就减1。 好了，问题来了，如果我有两个对象A和B，互相引用，除此之外，没有其他任何对象引用它们，实际上这两个对象已经无法访问，即是我们说的垃圾对象。但是互相引用，计数不为0，导致无法回收。所以有以下方式~
可达性分析算法
以根集对象为起始点进行搜索，如果有对象不可达的话，即是垃圾对象。这里的根集一般包括java栈中引用的对象、方法区常良池中引用的对象 本地方法中引用的对象等。 总之，JVM在做垃圾回收的时候，会检查堆中的所有对象是否会被这些根集对象引用，不能够被引用的对象就会被垃圾收集器回收。
[回收算法]
- 标记回收算法（Mark and Sweep GC）
从 GC Roots 集合开始，将内存整个遍历一次，保留所有可以被GC Roots直接或间接引用到的对象，而剩下的对象都当作垃圾对待并回收，这个算法需要中断进程内其它组件的执行并且可能产生内存碎片~
- 复制算法 (Copying）
将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收~
- 标记-压缩算法 (Mark-Compact)
先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高~
- 分代
将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。对于新生代适用于复制算法，而对于老年代则采取标记-压缩算法~
[Dalvik虚拟机]
[-GC类型]
GCFORMALLOC: 表示是在堆上分配对象时内存不足触发的GC。concurrent
GC_CONCURRENT: 当我们应用程序的堆内存达到一定量，或者可以理解为快要满的时候，系统会自动触发GC操作来释放内存。
GC_EXPLICIT: 表示是应用程序调用System.gc、VMRuntime.gc接口或者收到SIGUSR1信号时触发的GC。
GCBEFOREOOM: 表示是在准备抛OOM异常之前进行的最后努力而触发的GC。
[-回收和内存碎片]
主流的大部分Davik采取的都是标注与清理（Mark and Sweep）回收算法，也有实现了拷贝GC的，这一点和HotSpot是不一样的，具体使用什么算法是在编译期决定的，无法在运行的时候动态更换。如果在编译dalvik虚拟机的命令中指明了WITH_COPYING_GC选项，则编译/dalvik/vm/alloc/Copying.cpp源码 – 此是Android中复制算法 (Copying）的实现，否则编译/dalvik/vm/alloc/HeapSource.cpp – 其实现了标记回收算法（Mark and Sweep GC）。
由于Mark and Sweep算法的缺点，容易导致内存碎片，所以在这个算法下，当我们有大量不连续小内存的时候，再分配一个较大对象时，还是会非常容易导致GC，比如我们在该手机上decode图片。
所以对于Dalvik虚拟机的手机来说，我们首先要尽量避免掉频繁生成很多临时小变量（比如说：getView，onDraw等函数），另一个又要尽量去避免产生很多长生命周期的大对象。
[ART]
[-Java堆]
ART运行时内部使用的Java堆的主要组成包括Image Space、Zygote Space、Allocation Space和Large Object Space四个Space，Image Space用来存在一些预加载的类， Zygote Space和Allocation Space与Dalvik虚拟机垃圾收集机制中的Zygote堆和Active堆的作用是一样的。
[-GC类型]
kGcCauseForAlloc ，当要分配内存的时候发现内存不够的情况下引起的GC，这种情况下的GC会stop world
kGcCauseBackground，当内存达到一定的阀值的时候会去出发GC，这个时候是一个后台gc，不会引起stop world
kGcCauseExplicit，显示调用的时候进行的gc，如果art打开了这个选项的情况下，在system.gc的时候会进行gc
其他更多
[前后台GC]
前台Foreground指的就是应用程序在前台运行时，而后台Background就是应用程序在后台运行时。因此，Foreground GC就是应用程序在前台运行时执行的GC，而Background就是应用程序在后台运行时执行的GC。
应用程序在前台运行时，响应性是最重要的，因此也要求执行的GC是高效的。相反，应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题。因此，标记回收算法（Mark and Sweep GC）适合作为Foreground GC，而标记-压缩算法 (Mark-Compact)适合作为Background GC。
由于有Compact的能力存在，碎片化在Art上可以很好的被避免，这个也是Art一个很好的能力。
[ART对比DVM]
总的来看，art在gc上做的比dalvik好太多了，不光是gc的效率，减少pause时间，而且还在内存分配上对大内存的有单独的分配区域，同时还能有算法在后台做内存整理，减少内存碎片。对于开发者来说art下我们基本可以避免很多类似gc导致的卡顿问题了。另外根据谷歌自己的数据来看，Art相对Dalvik内存分配的效率提高了10倍，GC的效率提高了2-3倍。
[JVM、Dalvik和ART的区别]
什么是Dalvik
Dalvik是Google公司自己设计用于Android平台的Java虚拟机。dex格式是专为Dalvik应用设计的一种压缩格式，适合于内存和处理器速度有限的系统。Dalvik允许同时运行多个虚拟机的实例，并且每一个应用作为独立的Linux进程执行。独立的进程可以防止在虚拟机崩溃的时候所有程序都被关闭。
什么是ART
在Dalvik下，应用每次运行都需要通过即时编译器（JIT）将字节码转换为机器码，即每次都要编译加运行，这一机制并不高效，但让应用安装比较快，而且更容易在不同硬件和架构上运行。 ART完全改变了这种做法，在应用安装时就预编译字节码到机器语言，在移除解释代码这一过程后，应用程序执行将更有效率，启动更快。
Dalvik与JVM的区别
- Dalvik指令集是基于寄存器的架构，dex字节码更适合于内存和处理器速度有限的系统。
- 而JVM是基于栈的。相对而言，基于寄存器的Dalvik实现虽然牺牲了一些平台无关性，但是它在代码的执行效率上要更胜一筹。
Dalvik与ART的区别
- 在Dalvik下，应用每次运行都需要通过即时编译器（JIT）将字节码转换为机器码，即每次都要编译加运行，这虽然会使安装过程比较快，但是会拖慢应用以后每次启动的效率。而在ART 环境中，应用在第一次安装的时候，字节码就会预编译（AOT）成机器码，这样的话，虽然设备和应用的首次启动（安装慢了）会变慢，但是以后每次启动执行的时候，都可以直接运行，因此运行效率会提高。
- ART占用空间比Dalvik大（字节码变为机器码之后，可能会增加10%-20%），这也是著名的“空间换时间大法"。
- 预编译也可以明显改善电池续航，因为应用程序每次运行时不用重复编译了，从而减少了 CPU 的使用频率，降低了能耗。