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

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

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

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

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

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

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

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

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

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

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

随着用户量增加、系统并发增加，系统出现了频繁 Full GC，pinpoint 监控内存使用情况如下（只能监控老年代的 Full GC，而无法监控年轻代的 Minor GC，其实 Full GC 之前 Minor GC 执行次数频率更可怕）：

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

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

2.9 解决方案

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

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

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

清单如下：

属性类型

字节大小

int

4

long

8

float

4

double

8

byte

1

short

2

char

2

boolean

1

String

4

Refrerence

32位系统：4 or 64位系统：8

内存结构情况如下：

对象类型

内存布局构成

数组对象

8个字节对象头(mark) + 4/8字节对象指针 + 4字节数组长度 + 数据区 + padding内存对齐(按照8的倍数对齐)

非数组对象

8个字节对象头(mark) + 4/8字节对象指针 + 数据区 + padding内存对齐(按照8的倍数对齐)

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

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

Size(JavaBeanA) = Size(对象头(_mark)) + size(oop指针) + size(数据区)

Size(JavaBeanA) = 8 + 4 + 4(int) + 1(byte) + 4(String) * 26 + 8(double) + 7(padding) + 8(JavaBeanB指针)

Size(JavaBeanA) = 136 字节 = 136 / 1024 kb = 0.133 kb

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

对于生产系统，合理增大年轻代内存大小，本着尽量减少系统 Minor GC，一日最多一次 Full GC的原则；

优化编码，减少不必要的对象创建，合理定义对象，合理使用和优化数据结构；

优化 JVM 内存参数以减少 GC 次数，生产选择换最优垃圾收集器配置策略。