想写一篇关于android的内存分配和回收文章的想法来源于追查一个魅族手机图片滑动卡顿问题，我们想了很多办法还是没有避免他不停的gc，所以就打算详细的看看内存分配和gc的原理，为什么会不断的gc，gc alloc和gc cocurrent有什么区别，能不能想办法扩大堆内存减少gc的频次等等。
1、jvm内存回收机制
1.1 回收算法
标记回收算法（mark and sweep gc）
从"gc roots"集合开始，将内存整个遍历一次，保留所有可以被gc roots直接或间接引用到的对象，而剩下的对象都当作垃圾对待并回收，这个算法需要中断进程内其它组件的执行并且可能产生内存碎片
复制算法 (copying）
将现有的内存空间分为两快，每次只使用其中一块，在垃圾回收时将正在使用的内存中的存活对象复制到未被使用的内存块中，之后，清除正在使用的内存块中的所有对象，交换两个内存的角色，完成垃圾回收。
标记-压缩算法 (mark-compact)
先需要从根节点开始对所有可达对象做一次标记，但之后，它并不简单地清理未标记的对象，而是将所有的存活对象压缩到内存的一端。之后，清理边界外所有的空间。这种方法既避免了碎片的产生，又不需要两块相同的内存空间，因此，其性价比比较高。
分代
将所有的新建对象都放入称为年轻代的内存区域，年轻代的特点是对象会很快回收，因此，在年轻代就选择效率较高的复制算法。当一个对象经过几次回收后依然存活，对象就会被放入称为老生代的内存空间。对于新生代适用于复制算法，而对于老年代则采取标记-压缩算法。
1.2 复制和标记-压缩算法的区别
乍一看这两个算法似乎并没有多大的区别，都是标记了然后挪到另外的内存地址进行回收，那为什么不同的分代要使用不同的回收算法呢？
其实2者最大的区别在于前者是用空间换时间后者则是用时间换空间。
前者的在工作的时候是不没有独立的“mark”与“copy”阶段的，而是合在一起做一个动作，就叫scavenge（或evacuate，或者就叫copy）。也就是说，每发现一个这次收集中尚未访问过的活对象就直接copy到新地方，同时设置forwarding pointer。这样的工作方式就需要多一份空间。
后者在工作的时候则需要分别的mark与compact阶段，mark阶段用来发现并标记所有活的对象，然后compact阶段才移动对象来达到compact的目的。如果compact方式是sliding compaction，则在mark之后就可以按顺序一个个对象“滑动”到空间的某一侧。因为已经先遍历了整个空间里的对象图，知道所有的活对象了，所以移动的时候就可以在同一个空间内而不需要多一份空间。
所以新生代的回收会更快一点，老年代的回收则会需要更长时间，同时压缩阶段是会暂停应用的，所以给我们应该尽量避免对象出现在老年代。
2、dalvik虚拟机
2.1 java堆
java堆实际上是由一个active堆和一个zygote堆组成的，其中，zygote堆用来管理zygote进程在启动过程中预加载和创建的各种对象，而active堆是在zygote进程fork第一个子进程之前创建的。以后启动的所有应用程序进程是被zygote进程fork出来的，并都持有一个自己的dalvik虚拟机。在创建应用程序的过程中，dalvik虚拟机采用cow策略复制zygote进程的地址空间。
cow策略：一开始的时候（未复制zygote进程的地址空间的时候），应用程序进程和zygote进程共享了同一个用来分配对象的堆。当zygote进程或者应用程序进程对该堆进行写操作时，内核就会执行真正的拷贝操作，使得zygote进程和应用程序进程分别拥有自己的一份拷贝，这就是所谓的cow。因为copy是十分耗时的，所以必须尽量避免copy或者尽量少的copy。
为了实现这个目的，当创建第一个应用程序进程时，会将已经使用了的那部分堆内存划分为一部分，还没有使用的堆内存划分为另外一部分。前者就称为zygote堆，后者就称为active堆。这样只需把zygote堆中的内容复制给应用程序进程就可以了。以后无论是zygote进程，还是应用程序进程，当它们需要分配对象的时候，都在active堆上进行。这样就可以使得zygote堆尽可能少地被执行写操作，因而就可以减少执行写时拷贝的操作。在zygote堆里面分配的对象其实主要就是zygote进程在启动过程中预加载的类、资源和对象了。这意味着这些预加载的类、资源和对象可以在zygote进程和应用程序进程中做到长期共享。这样既能减少拷贝操作，还能减少对内存的需求。
2.2 对象分配和回收的几个数据指标
记得我们之前在优化魅族某手机的gc卡顿问题时，发现他很容易触发gc_for_malloc，这个gc类别后续会说到，是分配对象内存不足时导致的。可是我们又设置了很大的堆size为什么还会内存不够呢，这里需要了解以下几个概念：分别是java堆的起始大小（starting size）、最大值（maximum size）和增长上限值（growth limit）。
在启动dalvik虚拟机的时候，我们可以分别通过-xms、-xmx和-xx:heapgrowthlimit三个选项来指定上述三个值，以上三个值分别表示表示
starting size : dalvik虚拟机启动的时候，会先分配一块初始的堆内存给虚拟机使用。
growth limit:是系统给每一个程序的最大堆上限,超过这个上限，程序就会oom
maximum size：不受控情况下的最大堆内存大小，起始就是我们在用largeheap属性的时候，可以从系统获取的最大堆大小
同时除了上面的这个三个指标外，还有几个指标也是值得我们关注的，那就是堆最小空闲值（min free）、堆最大空闲值（max free）和堆目标利用率（target utilization）。假设在某一次gc之后，存活对象占用内存的大小为livesize，那么这时候堆的理想大小应该为(livesize / u)。但是(livesize / u)必须大于等于(livesize + minfree)并且小于等于(livesize + maxfree)，每次gc后垃圾回收器都会尽量让堆的利用率往目标利用率靠拢。所以当我们尝试手动去生成一些几百k的对象，试图去扩大可用堆大小的时候，反而会导致频繁的gc，因为这些对象的分配会导致gc，而gc后会让堆内存回到合适的比例，而我们使用的局部变量很快会被回收理论上存活对象还是那么多，我们的堆大小也会缩减回来无法达到扩充的目的。
2.3 对象的分配和gc
1. 调用函数dvmheapsourcealloc在java堆上分配指定大小的内存。如果分配成功，那么就将分配得到的地址直接返回给调用者了。函数dvmheapsourcealloc在不改变java堆当前大小的前提下进行内存分配，这是属于轻量级的内存分配动作。
2. 如果上一步内存分配失败，这时候就需要执行一次gc了。不过如果gc线程已经在运行中，即gdvm.gcheap->gcrunning的值等于true，那么就直接调用函数dvmwaitforconcurrentgctocomplete等到gc执行完成就是了。否则的话，就需要调用函数gcformalloc来执行一次gc了，参数false表示不要回收软引用对象引用的对象。
3. gc执行完毕后，再次调用函数dvmheapsourcealloc尝试轻量级的内存分配操作。如果分配成功，那么就将分配得到的地址直接返回给调用者了。
4. 如果上一步内存分配失败，这时候就得考虑先将java堆的当前大小设置为dalvik虚拟机启动时指定的java堆最大值，再进行内存分配了。这是通过调用函数dvmheapsourceallocandgrow来实现的。
5. 如果调用函数dvmheapsourceallocandgrow分配内存成功，则直接将分配得到的地址直接返回给调用者了。
6. 如果上一步内存分配还是失败，这时候就得出狠招了。再次调用函数gcformalloc来执行gc。参数true表示要回收软引用对象引用的对象。
7. gc执行完毕，再次调用函数dvmheapsourceallocandgrow进行内存分配。这是最后一次努力了，成功与事都到此为止。
示例图如下：
2.4 gc的类型
gc_for_malloc:表示是在堆上分配对象时内存不足触发的gc。
gc_concurrent: 当我们应用程序的堆内存达到一定量，或者可以理解为快要满的时候，系统会自动触发gc操作来释放内存。
gc_for_malloc: 当我们的应用程序需要分配更多内存，可是现有内存已经不足的时候，系统会进行gc操作来释放内存。
gc_explicit:表示是应用程序调用system.gc、vmruntime.gc接口或者收到sigusr1信号时触发的gc。
gc_before_oom:表示是在准备抛oom异常之前进行的最后努力而触发的gc。
实际上，gc_for_malloc、gc_concurrent和gc_before_oom三种类型的gc都是在分配对象的过程触发的。
2.5 回收算法和内存碎片
主流的大部分davik采取的都是标注与清理（mark and sweep）回收算法，也有实现了拷贝gc的，这一点和hotspot是不一样的，具体使用什么算法是在编译期决定的，无法在运行的时候动态更换。如果在编译dalvik虚拟机的命令中指明了"with_copying_gc"选项，则编译"/dalvik/vm/alloc/copying.cpp"源码 – 此是android中拷贝gc算法的实现，否则编译"/dalvik/vm/alloc/heapsource.cpp" – 其实现了标注与清理gc算法。
由于mark and sweep算法的缺点，容易导致内存碎片，所以在这个算法下，当我们有大量不连续小内存的时候，再分配一个较大对象时，还是会非常容易导致gc，比如我们在该魅族手机上decode图片，具体情况如下：
3、art内存回收机制
3.1 java堆
art运行时内部使用的java堆的主要组成包括image space、zygote space、allocation space和large object space四个space，image space用来存在一些预加载的类， zygote space和allocation space与dalvik虚拟机垃圾收集机制中的zygote堆和active堆的作用是一样的，
large object space就是一些离散地址的集合，用来分配一些大对象从而提高了gc的管理效率和整体性能，类似如下图：
在下文的gc log中，我们也能看到在art的gc log中包含了los的信息，方便我们查看大内存的情况。
3.2 gc的类型
kgccauseforalloc ，当要分配内存的时候发现内存不够的情况下引起的gc，这种情况下的gc会stop world
kgccausebackground，当内存达到一定的阀值的时候会去出发gc，这个时候是一个后台gc，不会引起stop world
kgccauseexplicit，显示调用的时候进行的gc，如果art打开了这个选项的情况下，在system.gc的时候会进行gc
其他更多
3.2 并发和非并发gc
非并发gc
步骤1. 调用子类实现的成员函数initializephase执行gc初始化阶段。
步骤2. 挂起所有的art运行时线程。
步骤3. 调用子类实现的成员函数markingphase执行gc标记阶段。
步骤4. 调用子类实现的成员函数reclaimphase执行gc回收阶段。
步骤5. 恢复第2步挂起的art运行时线程。
步骤6. 调用子类实现的成员函数finishphase执行gc结束阶段。
并发gc
步骤2. 获取用于访问java堆的锁。
步骤3. 调用子类实现的成员函数markingphase执行gc并行标记阶段。
步骤4. 释放用于访问java堆的锁。
步骤5. 挂起所有的art运行时线程。
步骤6. 调用子类实现的成员函数handledirtyobjectsphase处理在gc并行标记阶段被修改的对象。。
步骤7. 恢复第4步挂起的art运行时线程。
步骤8. 重复第5到第7步，直到所有在gc并行阶段被修改的对象都处理完成。
步骤9. 获取用于访问java堆的锁。
步骤10. 调用子类实现的成员函数reclaimphase执行gc回收阶段。
步骤11. 释放用于访问java堆的锁。
步骤12. 调用子类实现的成员函数finishphase执行gc结束阶段。
所以不论是并发还是非并发，都会引起stopworld的情况出现，并发的情况下单次stopworld的时间会更短。
3.4 并发gc的优势
可以通过如下2张图来对比下并发gc和非并发gc
非并发gc：
3.5 前后台gc
前台foreground指的就是应用程序在前台运行时，而后台background就是应用程序在后台运行时。因此，foreground gc就是应用程序在前台运行时执行的gc，而background就是应用程序在后台运行时执行的gc。
应用程序在前台运行时，响应性是最重要的，因此也要求执行的gc是高效的。相反，应用程序在后台运行时，响应性不是最重要的，这时候就适合用来解决堆的内存碎片问题。因此，mark-sweep gc适合作为foreground gc，而mark-compact gc适合作为background gc。
3.6 art大法好
总的来看，art在gc上做的比dalvik好太多了，不光是gc的效率，减少pause时间，而且还在内存分配上对大内存的有单独的分配区域，同时还能有算法在后台做内存整理，减少内存碎片。对于开发者来说art下我们基本可以避免很多类似gc导致的卡顿问题了。另外根据谷歌自己的数据来看，art相对dalvik内存分配的效率提高了10倍，gc的效率提高了2-3倍。
4、gc log
当我们想要根据gc日志来追查一些gc可能造成的卡顿时，我们需要了解gc日志的组成，不同信息代表了什么含义。
4.1 dalvik gc日志
dalvik的日志格式基本如下：
dalvik log
gc_reason：就是我们上文提到的，是gc_alloc还是gc_concurrent，了解到不同的原因方便我们做不同的处理。
amount_freed：表示系统通过这次gc操作释放了多少内存
heap_stats：中会显示当前内存的空闲比例以及使用情况（活动对象所占内存 / 当前程序总内存）
pause_time：表示这次gc操作导致应用程序暂停的时间。关于这个暂停的时间，在2.3之前gc操作是不能并发进行的，也就是系统正在进行gc，那么应用程序就只能阻塞住等待gc结束。而自2.3之后，gc操作改成了并发的方式进行，就是说gc的过程中不会影响到应用程序的正常运行，但是在gc操作的开始和结束的时候会短暂阻塞一段时间，所以还有后续的一个total_time。
total_time:表示本次gc所花费的总时间和上面的pause_time,也就是stop all是不一样的，卡顿时间主要看上面的pause_time。
4.2 art gc日志
art log
基本情况和dalvik没有什么差别，gc的reason更多了，还多了一个os_space_status
los_space_status：large object space，大对象占用的空间，这部分内存并不是分配在堆上的，但仍属于应用程序内存空间，主要用来管理 bitmap 等占内存大的对象，避免因分配大内存导致堆频繁 gc。