关于CMS收集器与G1收集器

写这篇文章也是源于前几天阿里一面时被问到“CMS收集器有哪些措施让它比其他收集器更优秀时”回答不上来，文章参考《深入理解JAVA虚拟机》

CMS收集器介绍

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，是基于标记-清除算法实现的。
主要分为四个步骤：
1）初始标记：标记一下GC Roots能够直接关联到的对象，速度很快。
2）并发标记：从GC Roots直接关联到的对象开始遍历整个对象图，耗时长，但可以并发进行。
3）重新标记：修正并发标记期间，因为用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。
4）并发清除：清理删除已经死亡的对象。
初始标记与重新标记仍旧需要“STW”，并发标记和并发清除能与用户线程并发进行。
三个明显的缺点：

1. CMS收集器对于处理器资源敏感。即如果处理器核心数量不足4个时，需要占用较大的处理器运算资源。
2. 无法处理浮动垃圾，出现“Concurrent Mode Failure”失败进而导致一次完全的“STW”的Full GC。
3. 基于“标记-清除”算法，产生大量的空间碎片。

G1收集器

采用局部收集的设计思路和基于Region的内存布局形式的一款收集器。整体来看是基于“标记-整理”算法实现的。
G1不再坚持固定大小以及固定数量的分代区域划分，而是把连续的Java堆划分为多个大小相等的独立区域（Region），每一个Region可以根据需要扮演新生代、老年代等。
Humongous区域，专门用来存储大对象，如果对象大小超过了一个Region，可将多个Region进行拼接。
G1可以由用户指定期望的停顿时间，设置不同的期望停顿时间，可使得G1在不同的应用场景中取得关注吞吐量和关注延迟之间的最讲平衡。那么它为什么能够做到呢？
G1不追求一次把整个Java堆都清理干净，它追求能够应付应用的内存分配速率，应用在分配内存空间，同时收集器在收集，只要收集的速度能够跟上对象分配的速度，那么一切就很完美。