cms：以获取最短回收停顿时间为目标的收集器，基于并发“标记清理”实现
有人会好奇为什么标记清理算法会产生内存碎片！但是cms仍采用这种算法呢？
答案是：因为cms作为第一款实现用户线程和收集线程并发执行的收集器！当时的设计理念是减少停顿时间，最好是能并发执行！但是问题来了，如要用户线程也在执行，那么就不能轻易的改变堆中对象的内存地址！不然会导致用户线程无法定位引用对象，从而无法正常运行！而标记整理算法和复制算法都会移动存活的对象，这就与上面的策略不符！因此cms采用的是标记清理算法！
** 初始标记-->并发标记---->重新标记---->并发清理**
过程：
1、初始标记：独占puc，stop-the-world, 仅标记gcroots能直接关联的对象
2、并发标记：可以和用户线程并发执行，通过gcroots tracing 标记所有可达对象。
3、重新标记：独占cpu，stop-the-world, 对并发标记阶段****用户线程运行产生的垃圾对象进行标记修正,以及更新自我拯救那部分逃逸对象
4、并发清理：可以和用户线程并发执行，清理垃圾
优点:
并发，低停顿
缺点：
1、对cpu非常敏感：在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢
2、无法处理浮动垃圾：在最后一步并发清理过程中，用户线程执行也会产生垃圾，但是这部分垃圾是在标记之后，所以只有等**到下一次gc的时候清理掉，这部分垃圾叫浮动垃圾。由于并发清理的时候，用户线程也在运行，就需要保证用户线程在运行的时候需要留有部分内存以供使用。 但是当这部分内存不足以给用户线程正常使用时，就会出现一次 “concurrent mode failure”**，一旦出现了“concurrent mode failure”，便会开启后备方案，临时使用serialold收集器进行收集工作。
3、cms使用“标记-清理”法会产生大量的空间碎片，当碎片过多，将会给大对象空间的分配带来很大的麻烦，往往会出现老年代还有很大的空间但无法找到足够大的连续空间来分配当前对象，不得不提前触发一次fullgc，
为了解决这个问题cms提供了一个开关参数，用于在cms顶不住，要进行fullgc时开启内存碎片的合并整理过程，但是内存整理的过程是无法并发的，空间碎片没有了但是停顿时间变长了
cms 出现fullgc的原因：
1、年轻代晋升到老年代没有足够的连续空间，很有可能是内存碎片导致的，因此会触发full gc
2、在并发过程中jvm觉得在并发过程结束之前堆就会满，需要提前触发fullgc
cms失败后使用备案serialold收集器
g1：是一款面向服务端应用的垃圾收集器
初始标记-->并发标记---->最终标记---->筛选回收
** g1只有并发标记阶段能做到用户线程和回收线程并发执行！！！！**
g1可以不需要其它收集器配合就能独立管理整个gc堆
目标是替换掉cms收集器
特点：
1、并行与并发：g1能充分利用cpu、多核环境下的硬件优势，使用多个cpu（cpu或者cpu核心）来缩短stop-the-world停顿时间。部分其他收集器原本需要停顿java线程执行的gc动作，g1收集器仍然可以通过并发的方式让java程序继续执行。
2、分代收集：分代概念在g1中依然得以保留。**虽然g1可以不需要其它收集器配合就能独立管理整个gc堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次gc的旧对象以获取更好的收集效果。**也就是说g1可以自己管理新生代和老年代了。
3、空间整合，没有内存碎片产生：由于g1使用了独立区域（region）概念，g1从整体来看是基于“标记-整理”算法实现收集，从局部（两个region）上来看是基于“复制”算法实现的，但无论如何，这两种算法都意味着g1运作期间不会产生内存空间碎片。
在最后筛选回收阶段，对每个region里的回收对象价值（回收该区域的时间消耗和能得到的内存比值）最后进行排序，用户可以自定义停顿时间，那么g1就可以对部分的region进行回收！这使得停顿时间是用户自己可以控制的！！！！
但是每个region之间是有互相引用的依赖关系的！这导致在minorgc的时候会同时对老年代进行扫描（甚至是整个堆扫描），那就会导致minorgc的效率低下，时间变长！
如何解决？？？
维护一个remebered set集合来存放各个region之间的引用关系！当进行gc roots tracing 的时候就可以只扫描set里的关联region！而不用全堆扫描啦！！！
4、可预测的停顿：这是g1相对于cms的另一大优势，降低停顿时间是g1和cms共同的关注点，但g1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用这明确指定一个长度为m毫秒的时间片段内，消耗在垃圾收集上的时间不得超过n毫秒。
可预测的停顿什么意思呢？
g1可以有计划的避免在整个jav堆中进行垃圾收集，可以对每个region里的回收对象价值（回收该区域的时间消耗和能得到的内存比值）进行分析，在最后筛选回收阶段，对每个region里的回收对象价值（回收该区域的时间消耗和能得到的内存比值）最后进行排序，用户可以自定义停顿时间，那么g1就可以对部分的region进行回收！这使得停顿时间是用户自己可以控制的！！！！
与其它收集器相比，g1变化较大的是它将整个java堆划分为多个大小相等的独立区域（region），虽然还保留了新生代和来年代的概念，但新生代和老年代不再是物理隔离的了它们都是一部分region（不需要连续）的集合。同时，为了避免全堆扫描，g1使用了remembered set来管理相关的对象引用信息。当进行内存回收时 ，在gc根节点的枚举范围中加入remembered set即可保证不对全堆扫描也不会有遗漏了。
最后筛选回收阶段首先对各个region的回收价值和成本进行排序，根据用户所期望的gc停顿时间来制定回收计划（可预测的停顿），这一过程同样是需要停顿线程的，但sun公司透露这个阶段其实也可以做到并发，但考虑到停顿线程将大幅度提高收集效率，所以选择停顿。下图为g1收集器运行示意图：