回收流程

当我们在创建一个对象的时候，比如说new User()这行代码，JVM会到Eden中申请一块内存存放这个User对象信息，就像下图这个样子。

随着越来越多的对象的新建，这时候Eden与From放不开新建对象的时候，就会触发一次Young GC，ParNew回收器会使用户线程全部停止，也就是Stop The World，进行标记，找出那些活的对象，然后将它们复制到To这个区域内（To与From 轮着用），注意 是在To这个区域能放下的前提，如果放不开就直接送入老年代了，然后它会将Eden与From这两块内存清除掉，这里我们假如就User 这个对象存活，所以这个To能够方法开它，但是这个User对象年龄+1，它每躲过一次Young GC 它的年龄就会+1，如果年龄到了15岁，这时候就会被送到老年代中。

随着系统的运行，老年代的对象也会越来越多，当到达Full GC的一个阈值的时候，就会触发老年代的Full GC了，触发Full GC 的条件往往是前面带着一次Young GC ，Young GC 过后，存活的对象From活着To区域放不开，然后直接进入老年代，正好老年代也放不开这些内存了，需要触发一下Full GC 来回收一下老年代的垃圾为这些放不开的存活对象腾地方，如果Full GC 过后还是放不下，这时候就会触发OOM了，也就是我们常说的Out Of Memery。

ParNew垃圾回收器

ParNew垃圾回收器主打的就是多线程的垃圾回收机制，老版本的Serial垃圾回收器主打的是单线程垃圾回收，他们都是对新生代进行垃圾回收的，唯一的区别就是单线程和多线程的区别，垃圾回收的算法是一样的，都是复制回收算法。

那么如何指定垃圾回收器为ParNew呢？

很简单，只要使用“-XX:+UseParNewGC”选项，只要加入这个选项，JVM启动之后对新生代的垃圾回收就是使用的ParNew垃圾回收器了。

后边的过程，垃圾回收算法，以及升级到老年代条件就是上篇文章我们介绍的那样。

默认情况下，如果指定为ParNew垃圾回收器，它会给自己设置与CPU核心数相同的垃圾回收线程。

如果要自定义垃圾回收线程数，可以使用“-XX:ParallelGCThreads”参数即可，但一般不建议修改此参数。

CMS垃圾回收器

老年代我们一般使用CMS进行垃圾回收。它采用的是标记清理算法，其实也很简单，就是先标记出哪些对象是垃圾对象，然后把这些对象清理掉。

通过上图，我们会发现一个问题，这种算法会造成很多内存碎片，这种碎片是大小不一的，可能放不下一个对象，那么这块内存就被浪费掉了。

也可能因为内存碎片太多，导致内存利用率很低，从而频繁引发FULL GC。这就是CMS的一个缺点了。

那么当发生FULL GC后，可能会先引发“Stop the World”，然后再采用标记清除算法回收垃圾，这样会有什么问题？

之前我们介绍过，当发生“Stop the World”的时候，会停止一切工作线程，导致程序卡顿，所以CMS的垃圾回收方式其实不是这样的。

CMS采取的是垃圾回收线程和系统工作线程尽量同时执行的模式来处理垃圾回收的。

一共分为四个阶段：初始标记、并发标记、重新标记、并发清理。

我们一个一个来看。

首先CMS进行Full GC了，会先执行初始标记阶段，这个阶段会引发“Stop the World”状态，停止所有工作线程，然后标记出所有GC Roots直接引用的对象。

public class Main {
    private static SysUser1 sysUser1 = new SysUser1();
}
public class Main {
    private  SysUser2 sysUser2 = new SysUser2();
}

在这一阶段仅仅会标记出静态变量sysUser1这个对象，而不会去管sysUser2对象，因为它是实例变量引用的。

方法的局部变量和类的静态变量是GC Roots，但是类的实例变量不是GC Roots。

所以第一个阶段虽然会造成“Stop the World”，但是实际影响不大，因为仅仅标记了GC Roots直接引用的对象，不会耗时太久。

接下来进入第二阶段，并发标记阶段，这个阶段系统进程可以随意创建新的对象，正常运行。

在这一阶段中，可能有新的对象创建，也可能有旧的对象变成垃圾对象，CMS会尽可能对已有对象进行GC Roots追踪，看看类似sysUser2这种对象被谁引用了。

如果它被间接的引用了，那么此时就不需要回收它。

简单的理解，第二阶段就是对老年代所以对象进行GC Roots追踪，这个还是很耗费时间的，但由于没有停止系统工作线程，所以不会对系统产生影响。

接着进入第三阶段，重新标记阶段。

因为第二阶段系统正常运行，所以结束后一定还会存在新的存活对象和垃圾对象是未被标记的。

所以在第三阶段将会再次触发“Stop the World”状态，停止系统工作线程。

然后重新标记在第二阶段中新创建的对象和新成为垃圾的对象。

这一过程是很快的，因为要标记的对象其实是很少的。

最后重新恢复系统工作进程，进入第四阶段：并发清理阶段。

这一阶段系统正常运行，然后CMS会对之前已经标记过的对象进行垃圾清理。

这一阶段也是很耗时的，但系统还在正常运行，是并发进行的。

CMS垃圾回收器存在的问题

通过上文的介绍，相信小伙伴们对于CMS的基本工作原理有了一个认识，大家会发现CMS本身已经对垃圾回收机制进行了性能的优化，那么为什么我们在jvm调优时要减少Full GC的频率呢？

其实CMS还是存在性能问题呢，比如上文我们说过的内存碎片问题。

cpu资源消耗问题

另外我们来思考一下，在并发标记阶段和并发清理阶段是最耗时的，与工作线程同时运行，是不是会导致CPU资源的占用？

所以这两个阶段是比较耗费CPU资源的。

CMS默认启动的垃圾回收线程数是（CPU核心数+3）/4。

那么假如我们使用的是一个2核的处理器，那么CMS就会占用（2+3）/4=1个垃圾回收线程。

所以CMS这个并发机制的第一个问题就是消耗CPU的资源。

Concurrent Mode Failure问题

第二个问题是比较严重的问题，就是在并发清理阶段，CMS清理的其实是之前标记好的对象。

但是由于系统并发的运行着，所以可能会有新的对象进入老年代，同时变成垃圾对象，这种对象就是“浮动垃圾”。

因为他们虽然是垃圾对象，但没有被标记，所以不会被清理掉。

所以为了保证CMS垃圾回收期间，还有一定的内存空间让新对象进入老年代，一般会预留空间。

当老年代的内存占用达到一定的比例值了，就会触发Full GC。

“-XX:CMSInitiatingOccupancyFaction”参数可以设置这个比例值，jdk1.6里面默认的是92%。

也就是说老年代占用了92%的空间后，就会执行Full GC，预留8%空间给并发回收期间新进入老年代的对象。

那么如果说这个预留的空间不够了，会发生什么呢？

这个时候就会发生Concurrent Mode Failure，然后会自动使用“Serial Old”垃圾回收器替代CMS，强行执行“Stop the World”，重新进行GC Roots追踪，然后一次性回收掉垃圾对象后，再恢复系统工作进程。

这样一来系统卡死的时间可能就很长了。

所以实际生产环境中，这个自动触发GC的比例是可以合理优化一下的。但一般情况下都不需要优化。

内存碎片问题

内存碎片问题上文已经介绍过了，就是可能会频繁引发Full GC。

CMS有个参数“-XX:+UseCMSCompactAtFullCollection”，默认是打开的。

它的意思是在Full GC后要再次进行“Stop the World”，然后进行碎片整理工作。

还有一个参数“-XX:CMSFullGCsBeforeCompaction”，这个意思是执行多少次Full GC后再执行碎片整理，默认是0，意思是每次Full GC后进行碎片整理。

这两个参数一般情况下都不需要修改，因为本来我们就要减少Full GC的频率，在低频率下，每次进行碎片整理是没有问题的。