应对 多CPU和大内存的应用场景中，旨在大多数情况下，在可预测的垃圾回收时间内，获得更大的吞吐量为目标，G1垃圾收集器全面支持JDK7 update 4 及之后的版本，G1 的设计场景主要是：
（1）应用在高并发应用程序中像CMS垃圾收集器一样，快速响应 （2）在整理内存碎片空间上花费更短的停顿时间 （3）可预测的GC停顿时间 （4）更高的吞吐量 （5）小内存的Java堆也可以用G1
G1对比CMS垃圾收集器，主要有两个部分的不同区别：
A：使用更紧凑粗粒度的内存区域划分，简称region，它简化了收集管理，消除了之前垃圾收集器潜在的内存碎片问题,主要的方案： 这所以CMS存在内存碎片，是因为采用了标记清除，，原因在于CMS中的old 区 所占空间较大，且里面的存活对象一般较多，因此移动对象消耗资源，效率低，因此只有等待full gc 整理，而cms是根据所设置的占比来定期执行。而fullGC 一般由于old区域空间不足或者system.gc等触发。而G1 通过将 内存划分成多个region，采用了mixed gc ，维护了每个区域的优先级，gc时只选择部分垃圾多的old，采用标记，并发，重新，清除，整理。前四个步骤与cmS类似，但其中并发时所采用的策略大为不同。因此解决了此内存碎片的问题。
B：相比CMS，G1提供了可预测的GC停顿时间，允许用户指定渴望的暂定周期full gc ： 触发条件
young GC的平均晋升大小比目前old gen剩余的空间大，则不会触发young GC而是转为触发full GC（因为HotSpot VM的GC里，除了CMS的concurrent collection之外，其它能收集old gen的GC都会同时收集整个GC堆，包括young gen，所以不需要事先触发一次单独的young GC）；或者，如果有perm gen的话，要在perm gen分配空间但已经没有足够空间时，也要触发一次full GC；或者System.gc()、heap dump带GC，默认也是触发full GC。
作者：RednaxelaFX 链接：https://www.zhihu.com/question/41922036/answer/93079526 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。http://blog.csdn.net/u010454030/article/details/51755071
https://my.oschina.net/91jason/blog/493870?p=1
gc时的 GC_root 列表 一般比真正的GC_ROOT 大。
http://www.open-open.com/lib/view/open1482392048975.html#articleHeader4
http://blog.csdn.net/u010454030/article/details/51755071