GC原理及调优

本文介绍 GC 基础原理和理论，GC 调优方法思路和方法，基于 Hotspot jdk1.8，学习之后你将了解如何对生产系统出现的 GC 问题进行排查解决。

内容主要如下：

• GC 基础原理，涉及调优目标，GC 事件分类、JVM 内存分配策略、GC 日志分析等。
• CMS 原理及调优。
• GC 问题排查和解决思路。

GC 基础原理

GC 调优目标

大多数情况下对 Java 程序进行 GC 调优，主要关注两个目标：

• 响应速度（Responsiveness）：响应速度指程序或系统对一个请求的响应有多迅速。 比如，用户订单查询响应时间，对响应速度要求很高的系统，较大的停顿时间是不可接受的。调优的重点是在短的时间内快速响应。
• 吞吐量（Throughput）：吞吐量关注在一个特定时间段内应用系统的大工作量。 例如每小时批处理系统能完成的任务数量，在吞吐量方面优化的系统，较长的 GC 停顿时间也是可以接受的，因为高吞吐量应用更关心的是如何尽可能快地完成整个任务，不考虑快速响应用户请求。

GC 调优中，GC 导致的应用暂停时间影响系统响应速度，GC 处理线程的 CPU 使用率影响系统吞吐量。

GC 分代收集算法

现代的垃圾收集器基本都是采用分代收集算法，其主要思想： 将 Java 的堆内存逻辑上分成两块：新生代、老年代，针对不同存活周期、不同大小的对象采取不同的垃圾回收策略。

 新生代（Young Generation）

 

新生代又叫年轻代，大多数对象在新生代中被创建，很多对象的生命周期很短。

每次新生代的垃圾回收（又称 Young GC、Minor GC、YGC）后只有少量对象存活，所以使用复制算法，只需少量的复制操作成本就可以完成回收。

新生代内又分三个区：一个 Eden 区，两个 Survivor 区（S0、S1，又称From Survivor、To Survivor），大部分对象在 Eden 区中生成。

当 Eden 区满时，还存活的对象将被复制到两个 Survivor 区（中的一个）；当这个 Survivor 区满时，此区的存活且不满足晋升到老年代条件的对象将被复制到另外一个 Survivor 区。

对象每经历一次复制，年龄加 1，达到晋升年龄阈值后，转移到老年代。

老年代（Old Generation）

在新生代中经历了 N 次垃圾回收后仍然存活的对象，就会被放到老年代，该区域中对象存活率高。老年代的垃圾回收通常使用“标记-整理”算法。

GC 事件分类

根据垃圾收集回收的区域不同，垃圾收集主要分为：

• Young GC
• Old GC
• Full GC
• Mixed GC

①Young GC

新生代内存的垃圾收集事件称为 Young GC（又称 Minor GC），当 JVM 无法为新对象分配在新生代内存空间时总会触发 Young GC。

比如 Eden 区占满时，新对象分配频率越高，Young GC 的频率就越高。

Young GC 每次都会引起全线停顿（Stop-The-World），暂停所有的应用线程，停顿时间相对老年代 GC 造成的停顿，几乎可以忽略不计。

②Old GC 、Full GC、Mixed GC

Old GC：只清理老年代空间的 GC 事件，只有 CMS 的并发收集是这个模式。

Full GC：清理整个堆的 GC 事件，包括新生代、老年代、元空间等 。

Mixed GC：清理整个新生代以及部分老年代的 GC，只有 G1 有这个模式。

GC 日志分析

GC 日志是一个很重要的工具，它准确记录了每一次的 GC 的执行时间和执行结果，通过分析 GC 日志可以调优堆设置和 GC 设置，或者改进应用程序的对象分配模式。

开启的 JVM 启动参数如下：

-verbose:gc-XX:+PrintGCDetails-XX:+PrintGCDateStamps-XX:+PrintGCTimeStamps

 

常见的 Young GC、Full GC 日志含义如下：

 

 免费的 GC 日志图形分析工具推荐下面 2 个：

• GCViewer，下载 jar 包直接运行 。
• gceasy，Web 工具，上传 GC 日志在线使用。

内存分配策略

Java 提供的自动内存管理，可以归结为解决了对象的内存分配和回收的问题。

前面已经介绍了内存回收，下面介绍几条普遍的内存分配策略：

①对象优先在 Eden 区分配：大多数情况下，对象在先新生代 Eden 区中分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Young GC。

②大对象之间进入老年代：JVM 提供了一个对象大小阈值参数（-XX:PretenureSizeThreshold，默认值为 0，代表不管多大都是先在 Eden 中分配内存）。

大于参数设置的阈值值的对象直接在老年代分配，这样可以避免对象在 Eden 及两个 Survivor 直接发生大内存复制。

③长期存活的对象将进入老年代：对象每经历一次垃圾回收，且没被回收掉，它的年龄就增加 1，大于年龄阈值参数（-XX:MaxTenuringThreshold，默认 15）的对象，将晋升到老年代中。

④空间分配担保：当进行 Young GC 之前，JVM 需要预估：老年代是否能够容纳 Young GC 后新生代晋升到老年代的存活对象，以确定是否需要提前触发 GC 回收老年代空间，基于空间分配担保策略来计算。

continueSize，老年代大可用连续空间：

 Young GC 之后如果成功（Young GC 后晋升对象能放入老年代），则代表担保成功，不用再进行 Full GC，提高性能。

如果失败，则会出现“promotion failed”错误，代表担保失败，需要进行 Full GC。

⑤动态年龄判定：新生代对象的年龄可能没达到阈值（MaxTenuringThreshold 参数指定）就晋升老年代。

如果 Young GC 之后，新生代存活对象达到相同年龄所有对象大小的总和大于任意 Survivor 空间（S0+S1空间）的一半，此时 S0 或者 S1 区即将容纳不了存活的新生代对象。

年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到 MaxTenuringThreshold 中要求的年龄。

另外，如果 Young GC 后 S0 或 S1 区不足以容纳：未达到晋升老年代条件的新生代存活对象，会导致这些存活对象直接进入老年代，需要尽量避免。

CMS 原理及调优

 

名词解释

可达性分析算法：用于判断对象是否存活，基本思想是通过一系列称为“GC Root”的对象作为起点（常见的 GC Root 有系统类加载器、栈中的对象、处于激活状态的线程等），基于对象引用关系，从 GC Roots 开始向下搜索，所走过的路径称为引用链，当一个对象到 GC Root 没有引用链相连，证明对象不再存活。

Stop The World：GC 过程中分析对象引用关系，为了保障分析结果的准确性，需要通过停顿所有 Java 执行线程，保证引用关系不再动态变化，该停顿事件称为 Stop The World（STW）。

Safepoint：代码执行过程中的一些特殊位置，当线程执行到这些位置的时候，说明虚拟机当前的状态是安全的，如果有需要 GC，线程可以在这个位置暂停。

HotSpot 采用主动中断的方式，让执行线程在运行期轮询是否需要暂停的标志，若需要则中断挂起。

 

CMS 简介

CMS（Concurrent Mark and Sweep 并发-标记-清除），是一款基于并发、使用标记清除算法的垃圾回收算法，只针对老年代进行垃圾回收。

CMS 收集器工作时，尽可能让 GC 线程和用户线程并发执行，以达到降低 STW 时间的目的。

通过以下命令行参数，启用 CMS 垃圾收集器：

-XX:+UseConcMarkSweepGC

值得补充的是，下面介绍到的 CMS GC 是指老年代的 GC，而 Full GC 指的是整个堆的 GC 事件，包括新生代、老年代、元空间等，两者有所区分。

新生代垃圾回收

能与 CMS 搭配使用的新生代垃圾收集器有 Serial 收集器和 ParNew 收集器。

 

这 2 个收集器都采用标记复制算法，都会触发 STW 事件，停止所有的应用线程。不同之处在于，Serial 是单线程执行，ParNew 是多线程执行。

 

 

cms运行流程图如下

 

 老年代垃圾回收

 

 CMS GC 以获取小停顿时间为目的，尽可能减少 STW 时间，可以分为 7 个阶段：

阶段 1：初始标记（Initial Mark）

 此阶段的目标是标记老年代中所有存活的对象, 包括 GC Root 的直接引用, 以及由新生代中存活对象所引用的对象，触发第一次 STW 事件。

这个过程是支持多线程的（JDK7 之前单线程，JDK8 之后并行，可通过参数 CMSParallelInitialMarkEnabled 调整）。

 

阶段 2：并发标记（Concurrent Mark）

 此阶段 GC 线程和应用线程并发执行，遍历阶段 1 初始标记出来的存活对象，然后继续递归标记这些对象可达的对象。

 

阶段 3：并发预清理（Concurrent Preclean）

 此阶段 GC 线程和应用线程也是并发执行，因为阶段 2 是与应用线程并发执行，可能有些引用关系已经发生改变。

通过卡片标记（Card Marking），提前把老年代空间逻辑划分为相等大小的区域（Card）。

如果引用关系发生改变，JVM 会将发生改变的区域标记为“脏区”（Dirty Card），然后在本阶段，这些脏区会被找出来，刷新引用关系，清除“脏区”标记。

 

阶段 4：并发可取消的预清理（Concurrent Abortable Preclean）

此阶段也不停止应用线程。本阶段尝试在 STW 的最终标记阶段（Final Remark）之前尽可能地多做一些工作，以减少应用暂停时间。

在该阶段不断循环处理：标记老年代的可达对象、扫描处理 Dirty Card 区域中的对象，循环的终止条件有：

 

• 达到循环次数
• 达到循环执行时间阈值
• 新生代内存使用率达到阈值

阶段 5：最终标记（Final Remark）

这是 GC 事件中第二次（也是最后一次）STW 阶段，目标是完成老年代中所有存活对象的标记。

在此阶段执行：

• 遍历新生代对象，重新标记
• 根据 GC Roots，重新标记
• 遍历老年代的 Dirty Card，重新标记

阶段 6：并发清除（Concurrent Sweep）

此阶段与应用程序并发执行，不需要 STW 停顿，根据标记结果清除垃圾对象。

 

阶段 7：并发重置（Concurrent Reset）

 

此阶段与应用程序并发执行，重置 CMS 算法相关的内部数据, 为下一次 GC 循环做准备。

 

CMS 常见问题

①最终标记阶段停顿时间过长问题

CMS 的 GC 停顿时间约 80% 都在最终标记阶段（Final Remark），若该阶段停顿时间过长，常见原因是新生代对老年代的无效引用，在上一阶段的并发可取消预清理阶段中，执行阈值时间内未完成循环，来不及触发 Young GC，清理这些无效引用。

通过添加参数：-XX:+CMSScavengeBeforeRemark。

在执行最终操作之前先触发 Young GC，从而减少新生代对老年代的无效引用，降低最终标记阶段的停顿。

但如果在上个阶段（并发可取消的预清理）已触发 Young GC，也会重复触发 Young GC。

 

②并发模式失败（concurrent mode failure）&晋升失败（promotion failed）问题。

 并发模式失败：当 CMS 在执行回收时，新生代发生垃圾回收，同时老年代又没有足够的空间容纳晋升的对象时，CMS 垃圾回收就会退化成单线程的 Full GC。所有的应用线程都会被暂停，老年代中所有的无效对象都被回收。

 晋升失败：当新生代发生垃圾回收，老年代有足够的空间可以容纳晋升的对象，但是由于空闲空间的碎片化，导致晋升失败，此时会触发单线程且带压缩动作的 Full GC。

并发模式失败和晋升失败都会导致长时间的停顿，常见解决思路如下：

• 降低触发 CMS GC 的阈值。 即参数 -XX:CMSInitiatingOccupancyFraction 的值，让 CMS GC 尽早执行，以保证有足够的空间。
• 增加 CMS 线程数，即参数 -XX:ConcGCThreads。
• 增大老年代空间。
• 让对象尽量在新生代回收，避免进入老年代。

③内存碎片问题

通常 CMS 的 GC 过程基于标记清除算法，不带压缩动作，导致越来越多的内存碎片需要压缩。

常见以下场景会触发内存碎片压缩：

• 新生代 Young GC 出现新生代晋升担保失败（promotion failed)）
• 程序主动执行System.gc

可通过参数 CMSFullGCsBeforeCompaction 的值，设置多少次 Full GC 触发一次压缩。

默认值为 0，代表每次进入 Full GC 都会触发压缩，带压缩动作的算法为上面提到的单线程 Serial Old 算法，暂停时间（STW）时间挺长，需要尽可能减少压缩时间。

 

调优方法与思路

如何分析系统 JVM GC 运行状况及合理优化？

GC 优化的核心思路在于：尽可能让对象在新生代中分配和回收，尽量避免过多对象进入老年代，导致对老年代频繁进行垃圾回收，同时给系统足够的内存减少新生代垃圾回收次数，进行系统分析和优化也是围绕着这个思路展开。

分析系统的运行状况

分析系统的运行状况：

• 系统每秒请求数、每个请求创建多少对象，占用多少内存。
• Young GC 触发频率、对象进入老年代的速率。
• 老年代占用内存、Full GC 触发频率、Full GC 触发的原因、长时间 Full GC 的原因。

 

常用工具如下：

jstat：JVM自带命令行工具，可用于统计内存分配速率、GC 次数，GC 耗时。

常用命令格式：

jstat -gc <pid><统计间隔时间><统计次数>

 

输出返回值代表含义如下：