垃圾回收器

对于新生代和旧生代，

JVM可使用很多种垃圾回收器进行垃圾回收，下图展示了不同生代不通垃圾回收器，其中两个回收器之间有连线表示这两个回收器可以同时使用。

 

 

 而这些垃圾回收器又分为串行回收方式、并行回收方式合并发回收方式执行，分别运用于不同的场景。如下图所示

 

 下面我们来逐一介绍一下每个垃圾回收器。

 

1、    Serial收集器

看名字我们都可以看的出来，这个属于串行收集器。其运行示意图如下

 

 

 

 Serial

收集器是历史最悠久的一个回收器，JDK1.3之前广泛使用这个收集器，目前也是ClientVM下 ServerVM 4核4GB以下机器的默认垃圾回收器。串行收集器并不是只能使用一个CPU进行收集，而是当JVM需要进行垃圾回收的时候，需要中断所有的用户线程，知道它回收结束为止，因此又号称“Stop The World” 的垃圾回收器。注意，JVM中文名称为java虚拟机，因此它就像一台虚拟的电脑一样在工作，而其中的每一个线程就被认为是JVM的一个处理器，因此大家看到图中的CPU0、CPU1实际为用户的线程，而不是真正机器的CPU，大家不要误解哦。

 

串行回收方式适合低端机器，是Client模式下的默认收集器，对CPU和内存的消耗不高，适合用户交互比较少，后台任务较多的系统。

Serial收集器默认新旧生代的回收器搭配为Serial+ SerialOld

2、    ParNew收集器

ParNew收集器其实就是多线程版本的Serial收集器，其运行示意图如下

 

 

 

  

 同样有

Stop The World的问题，他是多CPU模式下的首选回收器（该回收器在单CPU的环境下回收效率远远低于Serial收集器，所以一定要注意场景哦），也是Server模式下的默认收集器。

 

3、    ParallelScavenge

ParallelScavenge又被称为是吞吐量优先的收集器，器运行示意图如下

 

 

 

 

 ParallelScavenge

所提到的吞吐量=程序运行时间/(JVM执行回收的时间+程序运行时间),假设程序运行了100分钟，JVM的垃圾回收占用1分钟，那么吞吐量就是99%。在当今网络告诉发达的今天，良好的响应速度是提升用户体验的一个重要指标，多核并行云计算的发展要求程序尽可能的使用CPU和内存资源，尽快的计算出最终结果，因此在交互不多的云端，比较适合使用该回收器。

 

4、    ParallelOld

ParallelOld是老生代并行收集器的一种，使用标记整理算法、是老生代吞吐量优先的一个收集器。这个收集器是JDK1.6之后刚引入的一款收集器，我们看之前那个图之间的关联关系可以看到，早期没有ParallelOld之前，吞吐量优先的收集器老生代只能使用串行回收收集器，大大的拖累了吞吐量优先的性能，自从JDK1.6之后，才能真正做到较高效率的吞吐量优先。其运行示意图如下

 

 

 

  

 5、

    SerialOld

 

SerialOld是旧生代Client模式下的默认收集器，单线程执行；在JDK1.6之前也是ParallelScvenge回收新生代模式下旧生代的默认收集器，同时也是并发收集器CMS回收失败后的备用收集器。其运行示意图如下

 

 

 

 6、

    CMS

 

CMS又称响应时间优先(最短回收停顿)的回收器，使用并发模式回收垃圾，使用标记-清除算法，CMS对CPU是非常敏感的，它的回收线程数=（CPU+3）/4，因此当CPU是2核的实惠，回收线程将占用的CPU资源的50%，而当CPU核心数为4时仅占用25%。他的运行示意图如下

 

 

 

 CMS

模式主要分为4个过程

 

 

 

  

 在初始标记的时候，需要中断所有用户线程，在并发标记阶段，用户线程和标记线程

并发执行，而在这个过程中，随着内存引用关系的变化，可能会发生原来标记的对象被释放，进而引发新的垃圾，因此可能会产生一系列的浮动垃圾，不能被回收。

 

CMS 为了确保能够扫描到所有的对象，避免在Initial Marking 中还有未标识到的对象，采用的方法为找到标记了的对象，并将这些对象放入Stack 中，扫描时寻找此对象依赖的对象，如果依赖的对象的地址在其之前，则将此对象进行标记，并同时放入Stack 中，如依赖的对象地址在其之后，则仅标记该对象。

在进行Concurrent Marking 时minor GC 也可能会同时进行，这个时候很容易造成旧生代对象引用关系改变，CMS 为了应对这样的并发现象，提供了一个Mod Union Table 来进行记录，在这个Mod Union Table中记录每次minor GC 后修改了的Card 的信息。这也是ParallelScavenge不能和CMS一起使用的原因。

CMS产生浮动垃圾的情况请见如下示意图

 

 

 

在运行回收过后，c就变成了浮动垃圾。

由于CMS会产生浮动垃圾，当回收过后，浮动垃圾如果产生过多，同时因为使用标记-清除算法会产生碎片，可能会导致回收过后的连续空间仍然不能容纳新生代移动过来或者新创建的大资源，因此会导致CMS回收失败，进而触发另外一次FULL GC，而这时候则采用SerialOld进行二次回收。

同时CMS因为可能产生浮动垃圾，而CMS在执行回收的同时新生代也有可能在进行回收操作，为了保证旧生代能够存放新生代转移过来的数据，CMS在旧生代内存到达全部容量的68%就触发了CMS的回收！

7、    GarbageFirst(G1 )

我们再来看垃圾回收器的总图，刚才我们可以看到，我在图上标记了一个？，其实这是一个新的垃圾回收器，既可以回收新生代也可以回收旧生代，SunHotSpot 1.6u14以上EarlyAccess版本加入了这个回收器，sun公司预期SunHotSpot1.7发布正式版，他是商用高性能垃圾回收器，通过重新划分内存区域，整合优化CMS，同时注重吞吐量和响应时间，但是杯具的是被oracle收购之后这个收集器属于商用收费收集器，因此目前基本上没有人使用，我们在这里也就不多介绍，更多信息可以参考oracle新版本JDK说明。