jvm的垃圾回收算法有哪些

        jvm的垃圾回收算法有标记-清除、复制、标记-整理、分代回收算法，它们分别有不同的实现：

一、标记-清除算法

        利用可达性分析算法分析之后，将未被标记的对象[即不可达对象]清除，以便回收它们所占用的内存。

缺点：

        1、需要对内存进行两次遍历，一次遍历标记，一次遍历清除，效率较低；

        2、这种算法会造成大量的内存碎片，以至于出现当我们需要一片连续的大的内存空间去存储对象的时候无法找到合适的内存。

        CMS收集器就是用的标记-清除算法，CMS为了解决碎片式内存提供了内存合并整理的功能，但是这个功能的执行会导致用户线程暂停，会延长STW，导致程序性能下降。

二、复制算法：

        为了解决清除算法的内存碎片问题，复制算法将内存一分为二，每次只使用一半的内存去存储对象，当这一半内存不够用的时候触发gc，将存活下来的对象移到另外一半内存，然后将当前这一半内存清空，以便在下一次gc的时候使用。

        复制算法是没有标记过程的，它在可达性分析的过程中将存活的对象直接复制到另一半内存。而标记过程是为了找出未被标记的对象来进行清除。

缺点

        每次只能使用一半内存，内存使用率低，gc频繁。

改进

        在新生代中，因为大部分的对象都是朝生夕死，每次gc存活下来的对象占比很少，所以将新生代按照8:1:1的比例划分为Eden、survivor from、survivor to三个区，每次minor gc时，都是将eden和一个survivor区存活下来的对象复制到另外一个survivor区，然后清空eden和对应的survivor区。虽然我们其实是无法保证每次minor gc过后存活下来的对象占比永远低于10%，但是有老年代为新生代做内存兜底，当存活下来的对象在另一个survivor区保存不下时，将这些对象转移到老年代。

三、标记-整理算法 

         先对对象进行标记，然后将存活下来的对象向内存的一端移动，然后回收不再存活的对象所占用的内存。标记整理算法是针对于老年代提出来的算法，因为老年代的大部分对象都是经过了很多次gc之后仍然存活的对象，这些对象生存率高，如果对它们使用复制算法的话，就会造成一次次的复制而浪费时间。

四、分代收集算法 

        因为新生代和老年代的对象有着不同的特点，新生代存放的是大部分的新创建的对象，这些对象大部分都是朝生夕死，因此每次minor gc都会有大量的对象被回收；而老年代的对象是经历了多次gc依然存活下来的对象，老年代中的对象存活率高。所以我们不适合将新生代和老年代的对象一起gc，新生代和老年代适合不同的gc算法，并且适合在不同的时机去触发gc。新生代使用复制算法，老年代使用标记整理或清除算法。现在的商用的虚拟机都是使用分代收集。 

---

 

CMS和G1 

        cms收集器只回收老年代，使用标记-清除算法；G1既回收新生代又回收老年代，使用标记-整理算法。

        CMS因为其使用的是标记-清除算法，所以会有个严重问题就是在gc之后产生大量的内存碎片，当我们无法找到一块儿足够大的连续内存去存储对象的时候，就不得不再一次触发gc。

        G1打破了原有的对于堆的分代概念，将堆分为一个个大小相等的region，并且提供了可预测的停顿时间模型，使得我们可以去设置在一定的时长内所期望的停顿时间，在执行gc的时候，会将region按照回收价值和回收耗时进行排序，依据我们所设置的期望停顿时间去制定一个回收方案，回收部分region。

        G1的优势很明显，它无需和其他的收集器配合，自己便可以回收新生代和老年代；它支持可预期的停顿时间，提高了gc的效率。

垃圾回收的触发时机 

新生代垃圾回收触发时机：

        当 eden 区内存无法为一个新对象分配内存时，就会触发 Minor GC

老年代垃圾回收触发时机：

        1、如果没有设置-XX:+UseCMSInitiatingOccupancyOnly，虚拟机会根据收集的数据决定是否触发（建议线上环境带上这个参数，不然会加大问题排查的难度）。
        2、老年代使用率达到阈值 CMSInitiatingOccupancyFraction，默认92%。
        3、永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，默认92%，前提是开启 CMSClassUnloadingEnabled。
        4、新生代的晋升担保失败。老年代没有足够的空间来容纳全部的新生代对象或历史平均晋升到老年代的对象，如果不够的话，就提早进行一次老年代的回收，防止下次进行YGC的时候发生晋升失败。

老年代空间分配担保规则

        在执行任何一次Minor GC之前，JVM会先检查一下老年代的可用内存空间，是否大于新生代所有对象的总大小。因为在极端的情况下，可能新生代Minor GC过后，所有对象都存活下来了，并且所有对象全部要晋升到老年代，老年代得有足够的空间去存储它们。

        假如Minor GC之前，发现老年代的可用内存已经小于了新生代的全部对象大小了，就会看一下“-XX:-HandlePromotionFailure”的参数是否设置了如果有这个参数，那么就会继续尝试进行下一步判断。

        下一步判断，就是看看老年代的内存大小，是否大于之前每一次Minor GC后进入老年代的对象的平均大小。

        举个例子，之前每次Minor GC后，平均都有10MB左右的对象会进入老年代，那么此时老年代可用内存大于10MB。

        这就说明，很可能这次Minor GC过后也是差不多10MB左右的对象会进入老年代，此时老年代空间是够的，

        如果上面那个步骤判断失败了，或者是“-XX:-HandlePromotionFailure”参数没设置，此时就会直接触发一次“Full GC”，就是对老年代进行垃圾回收，尽量腾出来一些内存空间，然后再执行Minor GC。

        如果上面两个步骤都判断成功了，那么就是说可以冒点风险尝试一下Minor GC。此时进行Minor GC有几种可能。

        第一种可能，Minor GC过后，剩余的存活对象的大小，是小于Survivor区的大小的，那么此时存活对象进入Survivor区域即可。

        第二种可能，Minor GC过后，剩余的存活对象的大小，是大于 Survivor区域的大小，但是是小于老年代可用内存大小的，此时就直接进入老年代即可。

        第三种可能，很不幸，Minor GC过后，剩余的存活对象的大小，大于了Survivor区域的大小，也大于了老年代可用内存的大小。此时老年代都放不下这些存活对象了，就会发生“Handle Promotion Failure”的情况，这个时候就会触发一次“Full GC”。

        Full GC就是对老年代进行垃圾回收，同时也一般会对新生代进行垃圾回收。因为这个时候必须得把老年代里的没人引用的对象给回收掉，然后才可能让Minor GC过后剩余的存活对象进入老年代里面。如果要是Full GC过后，老年代还是没有足够的空间存放Minor GC过后的剩余存活对象，那么此时就会导致所谓的“OOM”内存溢出了。因为内存实在是不够了，你还是要不停的往里面放对象，当然就崩溃了。