不同的垃圾回收器的比较以及使用调查

垃圾回收器分类

笼统地来说垃圾回收器可以分成四种，如果要细分，可以分成七种。

粗分法：

1.串行回收器

2.并行/吞吐量回收器

3.CMS回收器

4.G1回收器

细分法：

• Serial：串行收集器，当进行垃圾收集时，会暂停所有线程
• Parallel：并行收集器，是串行收集器的多线程版本，多CPU下
• ParallelOld：老年代的Parallel版本
• ConcMarkSweep：简称CMS，是并发收集器，将部分操作与用户线程并发执行
• CMSIncrementalMode：CMS收集器变种，属增量式垃圾收集器，在并发标记和并发清理时交替运行垃圾收集器和用户线程
• G1：面向服务器端应用的垃圾收集器，计划未来替代CMS收集器

4款Java垃圾回收器（粗分法）——错误的选择导致糟糕的性能

现在已经是2014年了，但是对大多数开发人员而言有两件事情仍然是个谜——垃圾回收以及异性（码农又被嘲笑了）。由于我对后者也不是特别了解，我想我还是试着说说前者吧，尤其是随着Java 8的到来，这个领域也发生了许多重大的变化及提升，其中最重要的莫过于持久代（PermGen）的删除以及一些令人振奋的新的优化（后面会陆续提及这些）。

说起垃圾回收，许多人都了解它的概念，也在日常的编程中有所应用。尽管如此，仍有许多我们不太了解的东西，而这正是痛苦的根源。关于JVM最大的误解就是认为它只有一个垃圾回收器，而事实上它有四个不同的回收器，每个都各有其长短。JVM并不会自动地选择某一个，这事还得落在你我的肩上，因为不同的回收器会带来吞吐量及应用的暂停时间的显著的差异。

这四种回收算法的共同之处在于它们都是分代的，也就是说它们将托管的堆分成了好几个区域，它假设堆中的许多对象的生命周期都很短，可以很快被回收掉。介绍这块内容的已经很多了，因此这里我打算直接讲一下这几个不同的算法，以及它们的长处及短处。

1.串行回收器

串行回收器是最简单的一个，你都不会考虑使用它，因为它主要是面向单线程环境的（比如说32位的或者Windows）以及比较小的堆。这个回收器工作的时候会将所有应用线程全部冻结，就这一点而言就使得它完全不可能会被服务端应用所采用。

如何使用它：你可以打开-XX:+UseSerialGC这个JVM参数来使用它。

2.并行/吞吐量回收器

下一个是并行回收器（ Parallel collector）。这是JVM的默认回收器。正如它的名字所说的那样，它的最大的优点就是它使用多个线程来扫描及压缩堆。它的缺点就是不管执行的是minor GC还是full GC它都会暂停应用线程。并行回收器最适合那些可以容许暂停的应用，它试图减少由回收器所引起的CPU开销。

3.CMS回收器

并行回收器之后就是CMS回收器了（concurrent-mark-sweep）。这个算法使用了多个线程（concurrent）来扫描堆并标记（mark）那些不再使用的可以回收(sweep)的对象。这个算法在两种情况下会进入一个”stop the world”的模式：当进行根对象的初始标记的时候 （老生代中线程入口点或静态变量可达的那些对象）以及当这个算法在并发运行的时候应用程序改变了堆的状态使得它不得不回去再次确认自己标记的对象都是正确的。

使用这个回收器最大的问题就是会碰到promotion failure，这是指在回收新生代及年老代时出现了竞争条件的情况。如果回收器需要将年轻的对象提升到年老代中，而这个时候年老代没有多余的空间了，它就只能先进行一次STW(Stop The World)的full GC了——这种情况正是CMS所希望避免的。为了确保这种情况不会发生，你要么就是增加老生代的大小（或者增加整个堆的大小），要么就是给回收器分配一些后台线程以便与对象分配的速度进行赛跑。

这个算法的另一个缺点就是和并行回收器相比，它使用的CPU资源会更多，它使用了多个线程来执行扫描和回收，这样才能让应用持续提供更高级别的吞吐量。对于大多数长期运行的程序而言，应用的暂停对它们是很不利的，这个时候可以考虑使用CMS回收器。尽管如此，这个算法也不是默认开启的。你得指定XX:+UseConcMarkSweepGC来启用它。假设你的堆小于4G，而你又希望分配更多的CPU资源以避免应用暂停，那么这就是你要选择的回收器。然而，如果堆大于4G的话，你可能更希望使用最后的这个——G1回收器。

4.G1回收器

G1（ Garbage first）回收器在JDK 7update 4中首次引入，它的设计目标是能更好地支持大于4GB的堆。G1回收器将堆分为多个区域，大小从1MB到32MB不等，并使用多个后台线程来扫描它们。G1回收器会优先扫描那些包含垃圾最多的区域，这正是它的名字的由来（Garbage first）。这个回收器可以通过-XX:UseG1GC标记来启用。

这一策略减少了后台线程还未扫描完无用对象前堆就已经用光的可能性，而那种情况回收器就必须得暂停应用，这就会导致STW回收。G1的另一个好处就是它总是会进行堆的压缩，而CMS回收器只有在full GC的时候才会干这事。

过去几年里，大堆一直都是一个充满争议的领域，很多开发人员从单机器单JVM模型转向了单机器多JVM的微服务，组件化的架构。这是许多因素所驱动的，包括隔离程序的组件，简化部署，避免重新加载应用类到内存所产生的开销（Java 8中这点已经得到了改善）。

尽管如此，这么做最主要还是希望能避免大堆的GC中长时期的”stop the world”的暂停（在一次大的回收中需要花费数秒才能完成）。像Docker这样的容器技术也加速了这一进程，它们使得你可以很轻松地在同一台物理机上部署多个应用。

Java 8及G1回收器

Java 8 update 20所引入的一个很棒的优化就是G1回收器中的字符串去重（String deduplication）。由于字符串(包括它们内部的char[]数组）占用了大多数的堆空间，这项新的优化旨在使得G1回收器能识别出堆中那些重复出现的字符串并将它们指向同一个内部的char[]数组，以避免同一个字符串的多份拷贝，那样堆的使用效率会变得很低。你可以使用-XX:+UseStringDeduplication这个JVM参数来试一下这个特性。

Java 8及持久代

Java 8中最大的改变就是持久代的移除，它原本是用来给类元数据，驻留字符串，静态变量来分配空间的。这在以前都是需要开发人员来针对那些会加载大量类的应用来专门进行堆比例的优化及调整。许多年来都是如此，这也正是许多OutOfMemory异常的根源，因此由JVM来接管它真是再好不过了。即便如此，它本身并不会减少开发人员将应用解耦到不同的JVM中的可能性。

每个回收器都有许多不同的开关和选项来进行调优，这可能会增加吞吐量，也可能会减少，这取决于你的应用的具体的行为了。在下一篇文章中我们会深入讲解配置这些算法的关键策略。

JVM垃圾收集器使用调查（细分法）

近日，Plumbr公司对特定垃圾收集器使用情况进行了一次调查研究，研究数据使用了84936个案例。在明确指定垃圾收集器的13%的案例中，并发收集器（CMS）使用次数最多；但大多数案例没有选择最佳垃圾收集器。

近日，Plumbr公司对特定垃圾收集器（GC）使用情况进行了一次调查研究。

本次研究的数据来自代表2670个不同使用环境的84936个案例。其中，13%的环境已经明确指定了一个垃圾收集器，其余的根据JVM而定。在指定了明确垃圾收集器的11062个案例中，根据每个垃圾收集器使用的统计次数，研究人员做出了下面的垃圾收集器使用比例统计饼图：

名词解释

• Serial：串行收集器，当进行垃圾收集时，会暂停所有线程
• Parallel：并行收集器，是串行收集器的多线程版本，多CPU下
• ParallelOld：老年代的Parallel版本
• ConcMarkSweep：简称CMS，是并发收集器，将部分操作与用户线程并发执行
• CMSIncrementalMode：CMS收集器变种，属增量式垃圾收集器，在并发标记和并发清理时交替运行垃圾收集器和用户线程
• G1：面向服务器端应用的垃圾收集器，计划未来替代CMS收集器

87%的案例没有指定垃圾收集器

在解释垃圾收集器使用情况的详情之前，我们先看下其他87%的案例为什么没有出现在上面的饼图中。从研究结果来看，有2个不同的原因导致了该情况的出现：

• JVM对于默认情况的处理十分合理，开发人员无需指定垃圾收集器
• 对部分团队来说，程序性能可能优先级不高，致使没有指定垃圾收集器

所以，研究团队没有采用使用默认垃圾收集器的JVM案例。话又说回来，默认的垃圾收集器又是什么呢？这个问题既简单又复杂。如果你运行在JVM的客户端模式（Client）下，JVM默认垃圾收集器是串行垃圾收集器（Serial GC，-XX:+USeSerialGC）；在JVM服务器模式（Server）下默认垃圾收集器是并行垃圾收集器（Parallel GC，-XX:+UseParallelGC）。至于是运行在JVM的客户端模式还是服务器模式，取决于下面情况：

大多数案例没有做出最佳选择

让我们回到已经明确指定垃圾收集器的13%的案例，但仅有一小部分用户的决策是按照上述表格中的建议进行的。据统计，只有31个案例根据自己的机器性能选择了最佳的串行垃圾收集器，考虑到当前服务大多运行在多核服务器上，这个可以理解。  

我们从上图可以看出，Parallel（并行）和ParallelOld使用次数很接近。如果觉得并行模式这一新生代收集器更符合你的需求，那就选择它。从第一张表格中我们也可以看出，并行垃圾收集器(Parallel)已经是大多数平台的默认选择。从这个方面讲，如果没有指定明确的垃圾收集器，也并不意味着默认使用的垃圾收集器不流行。

说到CMSIncrementalMode的使用情况，只有935个案例使用了该种垃圾收集器，相比而言，经典的CMS（ConcMarkSweep）则有6655个环境使用了它。这里提示下大家，在并发阶段，垃圾收集器线程会使用一个或多个处理器。增量式垃圾收集器是通过一定的回收算法，把一个长时间的中断，划分为很多个小的中断，以减少垃圾收集器对用户程序的影响。 

研究中还有一个结果就是G1的采用率，有826个环境使用了该种垃圾收集器。但同等条件来讲，G1比CMS性能表现会差一些。