场景描述
相信大家都了解 jps、jmap、jstack 等常用 java 堆栈输出命令，有过 dump、gc 分析的经验，面试中会经常被问到有关 JVM 问题，比如你是否了解你的程序在生产环境的基础配置，堆内存、栈内存怎么设置的，又是怎么估算的大小，或是垃圾回收器及回收垃圾算法的最佳使用策略。作为项目的核心开发人员，别把这些事当成是架构师要干的活，因为代码可是你一行一行码出来的，没人比你更清楚，你得负责从程序开发、黑白盒测试、项目验收、部署上线、集成交付、运维监控、用户体验等环节。越大的企业，项目模块分配的越细，这也并不代表你不需要了解整体系统的性能，其中任何一个环节出问题，都可能导致系统无法正常运行。
借由这次生产系统频繁宕机，我们总结一下 JVM 内存模型划分、JVM 启动堆内存相关参数配置及说明、各年龄代的垃圾回收器及回收过程、生产 GC 日志解读与分析、系统运行内存预估方法、启动参数如何优化等。希望通过这篇小记来和大家一起交流、一起学习。
正文
2.1 生产 GC日志文件
部分截图如下：
2.2 先看一下 jdk 1.8 的内存划分情况
按年龄划分为年轻代、老年代、元空间、本地方法区、虚拟机栈和程序计数器。下图详细说明了这几个内存分区的关系、JVM 参数说明、存储的相关内容及各内存分区的垃圾回收器及垃圾回收算法。
2.3 生产基础环境
说明如下：
JDK版本：jdk_1.8
Web容器：Tomcat
题外话：估计市面上都是玩微服务了吧，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 个阶段，每个阶段到底做了什么，（这个图很重要，是CMS垃圾回收器工作过程详解，其中主要是分了四个过程，初始化标记（会发生STW）、并发标记、重新标记（会发生STW）、并发清除，详见垃圾回收器）详情见以下流程图所示：
2.7 随着用户量增加、系统并发增加
系统出现了频繁 Full GC，pinpoint（是一个JVM内存监控软件）监控内存使用情况如下(只能监控老年代的 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 次数，生产选择换最优垃圾收集器配置策略。