垃圾回收器手册：为你的项目挑选最适合的自动内存管理工具

系列文章目录

---

前言

JVM一直是Java面试中必问的一项，了解各个垃圾回收器的优势和弊端，选择合适的垃圾回收器能更好的保证系统的稳定运行。

---

一、新生代和老年代算法的选择

我们知道Java中的堆分为年轻代和老年代，常见的算法有复制算法 ，标记-清除算法，标记-整理算法，我们首先思考一下该如何选择适合的算法呢？因为垃圾回收器只是垃圾回收算法的落地。

复制算法

复制算法的本质是将内存空间一分为二，分为两个大小相等的区域，将存活的对象复制到另外一个空闲的空间。我们不妨想一下，如果存活的对象非常多，那么复制起来是不是特别耗时了？那这样的话，复制算法就只能适合那些只有少量存活对象的区域使用，那么什么地方只有少量对象存活了？ ----- 年轻代 ，因为我们知道年轻代的对象都是朝生夕死的，所以年轻代适用于复制算法

标记-清除算法 & 标记整理算法

标记清除和标记整理算法，因为不涉及到对象的移动，所以比较适合对象存活时间比较长的区域。 ---- 老年代

二、常见的垃圾回收器

Serial收集器

它是一种单线程收集器，不仅仅意味着它只会使用一个CPU或者一条收集线程去完成垃圾收集工作，更重要的是其在进行垃圾收集的时候需要暂停其他线程。

优点： 简单高效，拥有很高的单线程收集效率
缺点： 收集过程需要暂停所有线程（即会发生STW, stop the world)
算法： 复制算法
适用范围：新生代
应用： Client模式下的默认新生代收集器

ParNew收集器

可以把这个收集器理解为Serial收集器的多线程版本。

优点：在多CPU时，比Serial效率高。
缺点：收集过程暂停所有应用程序线程，单CPU时比Serial效率差。
算法：复制算法
适用范围：新生代
应用：运行在Server模式下的虚拟机中首选的新生代收集器

Parallel Scavenge收集器

Parallel Scavenge收集器是一个新生代收集器，它也是使用复制算法的收集器，又是并行的多线程收集器，看上去和ParNew一样，但是Parallel Scanvenge更关注系统的吞吐量 。

吞吐量=运行用户代码的时间/(运行用户代码的时间+垃圾收集时间)
比如虚拟机总共运行了100分钟，垃圾收集时间用了1分钟，吞吐量=(100-1)/100=99%。
若吞吐量越大，意味着垃圾收集的时间越短，则用户代码可以充分利用CPU资源，尽快完成程序的运算任务。

-XX:MaxGCPauseMillis控制最大的垃圾收集停顿时间，
-XX:GCTimeRatio直接设置吞吐量的大小。

Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器，不同的是采用"标记-整理算法"，运行过程和Serial收集器一样。

Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和"标记-整理算法"进行垃圾回收。吞吐量优先

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取 最短回收停顿时间 为目标的收集器。
采用的是"标记-清除算法",整个过程分为4步

(1)初始标记 CMS initial mark 标记GC Roots能关联到的对象 Stop The World—>速度很快
(2)并发标记 CMS concurrent mark 进行GC Roots Tracing
(3)重新标记 CMS remark 修改并发标记因用户程序变动的内容 Stop The World
(4)并发清除 CMS concurrent Sweep

由于整个过程中，并发标记和并发清除，收集器线程可以与用户线程一起工作，所以总体上来说，CMS收集器的内存回收过程是与用户线程一起并发地执行的。

优点：并发收集、低停顿
缺点：产生大量空间碎片、并发阶段会降低吞吐量

G1收集器

使用G1收集器时，Java堆的内存布局与就与其他收集器有很大差别，它将整个Java堆划分为多个
大小相等的独立区域（Region），虽然还保留有新生代和老年代的概念，但新生代和老年代不再
是物理隔离的了，它们都是一部分Region（不需要连续）的集合。

工作过程可以分为如下几步

• 初始标记（Initial Marking） 标记一下GC Roots能够关联的对象，并且修改TAMS的值，需要暂停用户线程
• 并发标记（Concurrent Marking） 从GC Roots进行可达性分析，找出存活的对象，与用户线程并发执行
• 最终标记（Final Marking） 修正在并发标记阶段因为用户程序的并发执行导致变动的数据，需暂停用户线程
• 筛选回收（Live Data Counting and Evacuation） 对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间制定回收计划

JDK 7开始使用，JDK 8非常成熟，JDK 9默认的垃圾收集器，适用于新老生代。

判断是否需要使用G1收集器？
（1）50%以上的堆被存活对象占用
（2）对象分配和晋升的速度变化非常大
（3）垃圾回收时间比较长

三、系统吞吐量和停顿时间

在我们选合适的垃圾回收器之前，我们需要了解这两个概念。这两个是衡量垃圾回收器好坏的标准。这两个指标也是评价垃圾回收器好处的标准，其实调优也就是在观察者两个变量。

停顿时间：垃圾收集器进行垃圾回收终端应用执行响应的时间
吞吐量：运行用户代码时间/(运行用户代码时间+垃圾收集时间)

停顿时间越短就越适合需要和用户交互的程序，良好的响应速度能提升用户体验；
高吞吐量则可以高效地利用CPU时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任
务。

四、场景选择

• 串行收集器->Serial和Serial Old
  只能有一个垃圾回收线程执行，用户线程暂停。 适用于内存比较小的嵌入式设备 。

• 并行收集器[吞吐量优先]->Parallel Scanvenge、Parallel Old
  多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。 适用于科学计算、后台处理等若交互场景 。

• 并发收集器[停顿时间优先]->CMS、G1
  用户线程和垃圾收集线程同时执行(但并不一定是并行的，可能是交替执行的)，垃圾收集线程在执行的时候不会停顿用户线程的运行。 适用于相对时间有要求的场景，比如Web 。

五、如何选择合适的垃圾收集器

官网 https://docs.oracle.com/javase/8/docs/technotes/guides/vm/gctuning/collectors.html#sthr
ef28

1. 优先调整堆的大小让服务器自己来选择
2. 如果内存小于100M，使用串行收集器
3. 如果是单核，并且没有停顿时间要求，使用串行或JVM自己选
4. 如果允许停顿时间超过1秒，选择并行或JVM自己选
5. 如果响应时间最重要，并且不能超过1秒，使用并发收集器