各有所长的清洁工 —— Java虚拟机的垃圾收集器清单

带着问题阅读

导语

上一讲讲解了虚拟机进行垃圾收集的几种常用算法，这一讲，我们就要看看，这几种算法，或者说方法论，是如何在各种垃圾收集器中具体实现的，同时我们也将一起了解JVM中，到底有哪些垃圾收集器。

本文是 Java专栏Java虚拟机专题的第七讲，如果你觉得看完之后对你有所帮助，欢迎订阅本专栏，也欢迎您将本专栏分享给你身边的工程师同学。

在学习本节课程之前，建议您了解一下以下知识点：

垃圾收集器概览

本文讨论的垃圾收集器，是基于JDK 1.7 之后的虚拟机，这里面包含了大多数开发人员会遇到的垃圾收集器。这些收集器之间的关系如图所示：

这张上一篇博客的贴图，展示了7种作用于不同分代、各有各的特长的垃圾收集器。如果两个收集器之间有连线，则说明它们可以搭配使用。图中的问号，其实就是被寄予厚望的G1收集器，下文会详细介绍。

关于垃圾收集器

在正式介绍各自收集器之前，有以下几点，是读者需要先了解一下的：

没有最好的垃圾收集器 只有最好的收集器组合

到目前为止，还没有什么最好的收集器，更加没有万能收集器。就像战场上没有一套战无不胜的战法一样，有的只是针对某一次战事的绝佳战法。因此，下文将会逐一介绍这些收集器的特性、基本原理和使用场景，教会读者，如何根据自己应用的特点和要求，去选择最佳的垃圾收集器搭配。文中提到的一些参数，读者了解一下即可，后面会有单独一节课程，来给大家演示如何使用这些参数。

评价垃圾收集器的指标

评价特定场合一下，一款收集器的好坏，主要有两个指标：停顿时间和吞吐量。

停顿时间是指进行垃圾收集时，用户线程的暂停时间，也就是之前课程所说的“Stop The World”，一般来说，用户交互较为频繁的B/S应用更为重视停顿时间的长短，停顿时间越短，用户等待时间就越少，体验就越佳。

吞吐量是指用于执行用户线程的时间占总应用时间的比率，对于无需和用户进行交互的纯后台应用来说，停顿时间没那么重要，更看重的是吞吐量的大小，吞吐量越大，说明执行用户线程的时间更长，处理速度就越高。

解释执行和即时编译器

JVM有两种方式去执行编译器编译出来的.class字节码文件——解释器（）和即时编译器（Just In Time ）。

解释器就像一个老实本分的翻译家，逐字逐句的翻译，每遇到一个指令，就将它编译成本机的机器语言（ Code），然后执行，下次再遇到这一条指令，还会再编译一次；

而即时编译器，则像一个善于将外文翻译成地道的中文的翻译家，会对指令编译出来的机器语言进行执行效率的优化，并且把这个优化后的机器语言保存下来，下次遇到再这条的指令，就不需要编译，直接执行。