jvm几种回收算法 CMS与G1的区别

1、几种回收算法

JVM垃圾回收算法
Java应用程序不用程序员手动管理内存中的垃圾回收，是因为JVM有专门的垃圾回收线程做这件事。当内存不够用时，会自动触发回收。为了在效率和内存碎片之间均衡，衍生出了一系列的垃圾回收算法。

1.标记–清除算法
执行步骤：

标记：遍历整个内存区域，对需要回收的对象打上标记。
清除：再次遍历内存，对标记过的内存进行回收。
图解：

 

 

缺点：

效率问题；遍历了两次内存空间（第一次标记，第二次清除）。
空间问题：容易产生大量内存碎片，当再需要一块比较大的内存时，虽然总的可用内存是够的，但是由于太过分散，无法找到一块连续的且满足分配要求的，因而不得不再次触发一次GC。
2.复制算法
将内存划分为等大的两块，每次只使用其中的一块。当一块用完了，触发GC时，将该块中存活的对象复制到另一块区域，然后一次性清理掉这块没有用的内存。下次触发GC时将那块中存活的的又复制到这块，然后抹掉那块，循环往复。

图解：

优点

 

 

相对于标记–清理算法解决了内存的碎片化问题，因为复制的时候，会把存活的对象，聚拢在一起。
效率更高（清理内存时，记住首尾地址，一次性抹掉）。
缺点：

内存利用率不高，每次只能使用一半内存。8G的内存，只能使用4G，这个是无法接受的。
改进
研究发现，大多数对象都是“朝生夕死”的，即生命周期非常短。也就是说，在发生GC的时侯，其实大多数对象已经是待回收的了，还处于正常状态的对象很少。因为存活的特别少，所以在进行复制的时候，复制的对象就特别少，占用的空间也就特别小，完全不需要1：1划分内存空间。多了也是浪费，够分配就行（特殊情况不够存放再说）。
但是也有一部分对象生命周期特别长，比如缓存中的对象，还有一些别的对象等等。对于这些对象如果每次都要复制移动的话，就显的特别麻烦。另外如果某些对象特别大，如果复制的话，也放不下。因此根据对象的特点进行了分治。将整个堆划分为两大块：新生代和老年代，分别用于存放不同特点的对象。

 

新生代呢，存放生命周期短的对象及其体积小的对象。
老年代呢 ，存放生命周期长的 ，体积大的对象。
而且对于新生代和老年代采用了不同的垃圾回收算法。新生代使用复制算法：

将整个新生代按照8 ： 1 ： 1的比例划分为三块，最大的称为Eden（伊甸园）区，较小的两块分别称为To Survivor和From Survivor。

 

首次GC时，只需要将Eden存活的对象复制到To。然后将Eden区整体回收。再次GC时，将Eden和To存活的复制到From，循环往复这个过程。这样每次新生代中可用的内存就占整个新生代的90%，大大提高了内存利用率。

但不能保证每次存活的对象就永远少于新生代整体的10%，此时复制过去是存不下的。因此这里会用到老年代，进行分配担保，存不下的话将对象存储到老年代。若还不够，就会抛出OOM。另外如果一个对象在多次内存回收后，都还存活，也会进入老年代，这个次数通过
‐XX:+MaxTenuringThreshold控制，最大值为15.（对象头中的4个bit存放）。

3. 标记–整理算法
当对象的存活率比较高时，或者对象比较大时，用前面的复制算法这样复制过来，复制过去，没啥意义，且浪费时间。所以针对老年代提出了“标记整理”算法。

执行步骤：

标记：对需要回收的进行标记
整理：让存活的对象，向内存的一端移动，然后直接清理掉没有用的内存。
图解：

 

 

4、分代收集算法
分代收集算法其实没有什么新东西，就是上面新生代和老年代根据对象不同的特点，采用不同的算法进行回收，取名为分代收集。

对象怎样才会进入老年代呢？

提升：当对象足够老的时候，会晋升到老年代。怎么才能足够老呢？对象在多次垃圾回收后，依然存活，也就是多次从from->to 又从to->from 这样多次。jvm认为无需让这样的对象继续这样复制，因此将其晋升到老年代。
分配担保：默认的Survivor只占整个年轻代的10%，当从eden区复制到from / to的时候，存不下了，这个时候对象会被移动到老年代。-XX:PretenureSizeThreshold
大对象直接在老年代分配。
动态对象年龄判定：当eden区中，某一年龄的对象已经占用整个eden的一半了，那么大于或者等于这一年龄的对象都会进入老年代。

2、CMS和G1的区别

CMS：以获取最短回收停顿时间为目标的收集器，基于并发“标记清理”实现

过程：

1、初始标记：独占CPU，仅标记GCroots能直接关联的对象

2、并发标记：可以和用户线程并行执行，标记所有可达对象

3、重新标记：独占CPU(STW)，对并发标记阶段用户线程运行产生的垃圾对象进行标记修正

4、并发清理：可以和用户线程并行执行，清理垃圾

优点:

并发，低停顿

缺点：

1、对CPU非常敏感：在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢

2、无法处理浮动垃圾：在最后一步并发清理过程中，用户县城执行也会产生垃圾，但是这部分垃圾是在标记之后，所以只有等到下一次gc的时候清理掉，这部分垃圾叫浮动垃圾

3、CMS使用“标记-清理”法会产生大量的空间碎片，当碎片过多，将会给大对象空间的分配带来很大的麻烦，往往会出现老年代还有很大的空间但无法找到足够大的连续空间来分配当前对象，不得不提前触发一次FullGC，为了解决这个问题CMS提供了一个开关参数，用于在CMS顶不住，要进行FullGC时开启内存碎片的合并整理过程，但是内存整理的过程是无法并发的，空间碎片没有了但是停顿时间变长了

CMS 出现FullGC的原因：

1、年轻带晋升到老年带没有足够的连续空间，很有可能是内存碎片导致的

2、在并发过程中JVM觉得在并发过程结束之前堆就会满，需要提前触发FullGC

G1：是一款面向服务端应用的垃圾收集器

特点：

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运作期间不会产生内存空间碎片。

4、可预测的停顿：这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用这明确指定一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

与其它收集器相比，G1变化较大的是它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留了新生代和来年代的概念，但新生代和老年代不再是物理隔离的了它们都是一部分Region（不需要连续）的集合。同时，为了避免全堆扫描，G1使用了Remembered Set来管理相关的对象引用信息。当进行内存回收时，在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏了。

如果不计算维护Remembered Set的操作，G1收集器的运作大致可划分为以下几个步骤：

1、初始标记（Initial Making）

2、并发标记（Concurrent Marking）

3、最终标记（Final Marking）

4、筛选回收（Live Data Counting and Evacuation）

看上去跟CMS收集器的运作过程有几分相似，不过确实也这样。初始阶段仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS（Next Top Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可以用的Region中创建新对象，这个阶段需要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中对象进行可达性分析，找出存活对象，这一阶段耗时较长但能与用户线程并发运行。而最终标记阶段需要吧Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿线程，但可并行执行。最后筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，这一过程同样是需要停顿线程的，但Sun公司透露这个阶段其实也可以做到并发，但考虑到停顿线程将大幅度提高收集效率，所以选择停顿。下图为G1收集器运行示意图：