fullgc触发条件_记一次生产频繁出现 Full GC 的 GC日志图文详解

场景描述

相信大家都了解 jps、jmap、jstack 等常用 java 堆栈输出命令，有过 dump、gc 分析的经验，面试中会经常被问到有关 JVM 问题，比如你是否了解你的程序在生产环境的基础配置，堆内存、栈内存怎么设置的，又是怎么估算的大小，或是垃圾回收器及回收垃圾算法的最佳使用策略。作为项目的核心开发人员，别把这些事当成是架构师要干的活，因为代码可是你一行一行码出来的，没人比你更清楚，你得负责从程序开发、黑白盒测试、项目验收、部署上线、集成交付、运维监控、用户体验等环节。越大的企业，项目模块分配的越细，这也并不代表你不需要了解整体系统的性能，其中任何一个环节出问题，都可能导致系统无法正常运行。

借由这次生产系统频繁宕机，我们总结一下 JVM 内存模型划分、JVM 启动堆内存相关参数配置及说明、各年龄代的垃圾回收器及回收过程、生产 GC 日志解读与分析、系统运行内存预估方法、启动参数如何优化等。希望通过这篇小记来和大家一起交流、一起学习。

正文

2.1 生产 GC日志文件

部分截图如下：

2.2 先看一下 jdk 1.6 的内存划分情况

按年龄划分为年轻代、老年代、永久代(方法区)、本地方法区、虚拟机栈和程序计数器。下图详细说明了这几个内存分区的关系、JVM 参数说明、存储的相关内容及各内存分区的垃圾回收器及垃圾回收算法。

2.3 生产基础环境

说明如下：

• JDK版本：jdk_1.6
• Web容器：Weblogic

题外话：估计市面上都是玩微服务了吧，jdk 版本至少也得 1.8 以上，jdk 1.6 不支持 G1 这么好用的垃圾收集器，也不支持 lambda 表达式，以及其他好用的特性

2.4 生产 JVM 堆内存相关参数

设置如下：

// 初始堆大小-Xms4096M// 最大堆大小-Xmx4096M// 持久代最大值-XX:MaxPermSize=1024M//......

题外话：这份配置一看就有点问题，为什么到现在才发现，因为系统之前很少出现问题，之前也未设置GC日志记录参数，也未曾关心 JVM 参数设置，大家只是在原有的工程进行开发和维护。其中 -Xmn 年轻代未配置(-XX:NewRatio 年轻代与年老代所占比值也未配置)，-XX:PermSize 持久代初始值未配置(存在动态扩容带来的性能消耗)等

2.5 截取生产一条 GC 日志

图解分析如下：

2019-11-20T17:15:38.906+0800: 672725.775: [GC 2019-11-20T17:15:38.907+0800: 672725.776: [ParNew: 143735K->15199K(153344K), 0.0485240 secs] 2568043K->2439507K(4177280K), 0.0497750 secs] [Times: user=0.20 sys=0.00, real=0.05 secs] 

从以上 GC 日志文件结构图解可以清晰看出，线上生产环境的年轻代总内存大小分配约 150M，堆总内存大小约 4G，明显年轻代内存分配过小。每次 ParNew GC 老年代变化可以由堆内存大小变化和年轻代内存大小变化推算。

从下图 GC 日志可以看出，线上系统出现频繁 ParNew GC(即年轻代的 Minor GC)，平均大约每 5 分钟进行一次 Minor GC，即一天平均执行 288 次之多，太可怕了吧！！！唉

题外话：为什么这么频繁，系统都线上运行3年了，当初系统上线JVM启动参数应该是随便设置的，呵呵一是系统并发量不高，二是用户量不大，三是开发人员不注重JVM优化，四是到前不久才加上GC日志输出参数，五是 pinpoint 运维监控系统居然不支持 Minor GC的监控，只支持 Full GC 监控，呵呵

2.6 CMS (Concurrent Mark Sweep)

CMS 垃圾回收器进行一次 Full GC，GC日志部分截图如下所示：

从上图可以看出，CMS 垃圾回收器正常运行(CMS 垃圾回收触发的条件：当老年代内存达到92%(3719000K / 4023936K * 100% = 92%)，详情见下图)。对上图 CMS GC 进行剖析如下：

从图中可以清晰看到，CMS 对于老年代的垃圾回收分成 7 个阶段，每个阶段到底做了什么，详情见以下流程图所示：

2.7 随着用户量增加、系统并发增加

系统出现了频繁 Full GC，pinpoint 监控内存使用情况如下(只能监控老年代的 Full GC，而无法监控年轻代的 Minor GC，其实 Full GC 之前 Minor GC 执行次数频率更可怕)：

2.8 ParNew + CMS 组合

ParNew(年轻代垃圾回收器) + CMS(老年代垃圾回收器) 回收器组合是在 JDK 1.8 之前大多数 JAVA 企业级服务应用的最佳选择，从以下生产 GC 日志截图中可以看到，在 CMS 回收器触发时，出现了 promotion failed 和 concurrent mode failure 现象：

针对这两个现象产生的原因进行解读如下：

• promotion failed该现象是在进行触发年轻代 ParNew GC 时，存活的对象在 Survivor 区放不下，对象只能进入老年代，而此时老年代也放不下导致的。
• concurrent mode failure该现象是在执行 CMS 回收器回收垃圾的过程中同时有存活的对象放入老年代，而此时老年代空间不足，或者在做 ParNew GC 的时候，年轻代 Survivor 区放不下，需要放入老年代，而老年代也放不下而导致的。

2.9 解决方案

针对以上2种现象产生的原因进行 JVM 相关参数优化：

可增大年轻代或者 Survivor 区的存储空间

-Xmn1500M-XX:SurvivorRatio=8

或者提前触发 CMS 垃圾回收和进行 5 次 CMS 垃圾回收后整理清除碎片

-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80

2.10 最后对生产环境的 JVM 内存参数设置进行优化

建议虚拟机参数设置如下：

-Xms4096M-Xmx4096M-Xmn1500M-XX:PermSize=1024M-XX:MaxPermSize=1024M-Xss512K-XX:SurvivorRatio=8-XX:+UseConcMarkSweepGC-XX:+UseParNewGC-XX:+CMSParallelRemarkEnabled-XX:+UseCMSCompactAtFullCollection-XX:CMSFullGCsBeforeCompaction=5-XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=80-XX:+PrintGCDetails-XX:+PrintGCTimeStamps-Xloggc:log/gc.log

线上系统内存估算方法

3.1 Java对象属性类型所占字节大小

列表清单如下：

3.2 Java对象所占JVM内存结构

如下图展示：

可以看到数组类型对象和普通对象的区别仅在于 4 字节数组长度的存储区间。而对象指针究竟是 4 字节还是 8 字节要看是否开启指针压缩。Oracle JDK 从 6_update_23 开始在 64 位系统上会默认开启压缩指针。如果要强行关闭指针压缩使用 -XX:-UseCompressedOops，强行启用指针压缩使用：-XX:+UseCompressedOops。

假如生产订单某一对象大约30字段，如订单对象 JavaBeanA ，所占内存大小计算的方法如下所示：

public class ObjectA {          int a;       // 4 Byte         byte b;      // 1 Byte        String c;   // 4 Byte        double d;       // 8 Byte        String e;   // 4 Byte        // 此处省略25个String对象 25*4 Byte        ObjectB objB;  // 8 Byte }public class ObjectB {      // ...    }

Size(ObjectA) = Size(对象头(_mark)) + size(oop指针) + size(数据区)Size(ObjectA) = 8 + 4 + 4(int) + 1(byte) + 4(String) * 26 + 8(double) + 7(padding) + 8(ObjectB指针)Size(ObjectA) = 136 字节 = 136 / 1024 kb = 0.133 kb

由此，可以大约估算出你的线上系统每秒产生多少 M 的对象。如果每秒产生 500 个 ObjectA，即大约 0.5 M，那么对于年轻代 1500M 的内存，大约需要 3000s 充满，即 50 min才触发一次 Minor GC，也就是说一天大约触发24次 Minor GC

总结

• 对于生产系统，合理增大年轻代内存大小，本着尽量减少系统 Minor GC，一日最多一次 Full GC 的原则；
• 优化编码，减少不必要的对象创建，合理定义对象，合理使用和优化数据结构；
• 优化 JVM 内存参数以减少 GC 次数，生产选择换最优垃圾收集器配置策略。