JVM CMS和G1执行过程
看了很多的博客，感觉他们写的都过于专业，今日就想能不能用通俗易懂的语言将其描述清楚，将这两个收集器解决掉！！！
首先我们先了解一下CMS和G1是做什么的？
都是垃圾回收器
相同的地方：都是并发执行（垃圾收集线程与用户线程同步执行）
不同的地方：
关注点：CMS尽可能缩短垃圾收集时用户线程的停顿时间。G1实现可预期及可配置的用户线程停顿时间
算法：CMS标记-清除算法，G1复制算法，标记-整理算法
处理对象消失：CMS用的增量更新，G1用的原视快照
那么这两个垃圾回收器是怎么工作呢？
首先我们要了解这几个概念：可达性、并发标记出现的问题、对象消失、三色标记法
可达性：是以根对象集合（GCRoots）为起始点，按照从上至下的方式搜索被根对象集合所连接的目标对象是否可达，只有能够被根对象集合直接或者间接连接的对象才是存活对象。
三色标记法：
- 白色：表示该对象还没有被垃圾回收器访问。垃圾回收的最初阶段，所有对象都是白色的。
- 黑色：表示对象以及被垃圾回收器访问了，而且该对象的所有引用都已经被扫描过。标记为黑色的对象，意味着该对象是存活的。
- 灰色：位于白色与黑色中间态的对象，表示该对象已经被垃圾回收器访问过，但是它的引用还没有被扫描。
整个标记过程，就是沿着 GC Roots，整个对象结构图以灰色为波峰的波纹从黑向白推进的过程。最初除了 GC Roots 以外，所有对象都是白色；标记阶段不断的产生灰色和黑色对象；最后图中只剩下白色和黑色的对象，黑色就是存活的对象，白色就是可以被回收的对象
为什么会出现并发标记的问题：
因为是并发标记，此时垃圾回收线程和用户线程都是执行，那么就可能会再此期间会因为增删改对象，引起最终得到的标记结果不准确。
并发标记出现的问题：
- 浮动垃圾：将原本应该被清除的对象，误标记为存活对象。后果是垃圾回收不彻底，不过影响不大，可以在下个周期被回收；
- 对象消失：将原本应该存活的对象，误标记为需要清理的对象。后果很严重，影响程序运行，是不可容忍的。
如何解决并发标记出现的问题：
重点就是防止对象消失
如何防止：有一位很厉害的人提出了这样的结论
- 赋值器插入了一条或者多条从黑色对象到白色对象的新引用；
- 赋值器删除了全部从灰色对象到该白色对象的直接或间接引用。
这两个条件必须全部满足，才会出现对象消失的问题。那么我们只需要对上面条件进行破坏，破坏其中的任意一个，都可以防止对象消失问题的产生。这样就产生了两种解决方案：
- 增量更新：Incremental Update。
- 原始快照：Snapshot At The Beginning，SATB。
增量更新破坏的是第一个条件，当黑色对象插入新的指向白色对象的引用时，就将这个新加入的引用记录下来，待并发标记完成后，重新对这种新增的引用记录进行扫描；原始快照破坏的是第二个条件，当灰色对象要删除指向白色对象的引用关系时，也是将这个记录下来，并发标记完成后，对该记录进行重新扫描。
如果没有增量更新，黑色对象直接指向白色对象并不会扫描，因为黑色是已经扫描过的，不会再进行扫描，如果想要扫描白色对象，需要时灰色对象执行白色对象，这就是为什么需要增量更新，那么最后还会执行一次，从标记有执行白色对象的黑色对象为起点，再扫描一次（此时时STW），这样就解决了对象消失的问题，白色就有机会变为灰色，再变黑色了
如果没有原视快照，那么灰色对象删除了白色对象的引用，但是黑色对象此时引用着白色对象，但是黑色不会再执行扫描了，那么白色就会被垃圾回收掉，有了原视快照，那么，我们再删除灰色和白色之间的引用时，做一个记录，之后，再扫描一遍，如果白色有被引用，那么就将器变为灰色，进而转为黑色，不会回收。
（PS：JVM通过实现AOP切面对“引用对象赋值”操作进行监听，也就是实现增量更新和原始快照的底层原理，一增删改就会触发此机制）
最后，写一下CMS和G1的执行过程
CMS执行过程
1、初始标记：独占CPU（STW），标记从GC Root出发可以直接到达的对象
2、 并发标记：可以和用户线程并行执行，标记所有可达对象
3、 重新标记：独占CPU（STW），对并发标记期间用户线程运行产生的垃圾对象进行标记修正（用的是增量更新）---防止对象消失
4、 并发清理：可以和用户线程并行执行，清理垃圾
G1执行过程
1、初始标记：独占CPU（STW），标记从GC Root出发可以直接到达的对象
2、 并发标记：可以和用户线程并行执行，标记所有可达对象
3、最终标记：独占CPU（STW），对并发标记期间用户线程运行产生的垃圾对象进行标记修正（用的是原始快照）---防止对象消失
4、筛选回收：需要STW，但是也可以和用户线程并行执行，首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划