1.系统背景

这是当时开发中遇到的一个真实场景，也是大部分人在开发项目中有可能会遇到的一些场景，该系统主要是做大数据相关计算分析的，日处理数据量在上亿的规模。这里我们重点针对JVM内存的管理来进行模型分析，数据的来源获取主要是MYSQL数据库以及其他数据源里提取大量的数据，通过加载到JVM内存的过程我们来一起分析出现的问题以及如何优化解决（如下图所示）：

image

2.生产环境

这是一套分布式运行系统，生产环境部署了多台服务器（每台4核8G配置），每台机器大概每分钟负责执行100次数据提取和计算，每次提取大概1万条左右的数据到内存计算，平均每次计算需要耗费10秒左右时间。 JVM内存总共分配了4G，堆内存占3G，其中新生代和老年代分别是1.5G的内存空间

image

3.过程分析

按照上述的背景和实际生产环境，那每次1万条数据会占用多少的内存空间呢？这里每条数据较大，平均包含20个字段，可以认为每条数据大概在1KB左右。那么1万条数据对应就是10MB大小。那么运行多久就会导致新生代塞满呢？

新生代总共分配1.5G，那么Eden区分配就是1.2G，S1和S2区分别是150MB；如下图:

image

现在我们可以来手动计算下了，1次往Eden区里填充10MB对象，1分钟读取100次，也就是差不多1个G，那也就是1分钟左右的时候我们的Eden区就差不多填满了，这个时候如果触发Minor GC，我们通过上文学习知道，JVM在执行Minor GC之前是会进行一步检查动作的：老年代可用内存空间是否大于新生代全部对象？如果是第一次运行到这儿，那么我们的老年代是空的，也就是有1.5G的空间，完全是够用的。

image

这里触发Minor GC进行回收，但是问题在于如何回收呢？我们重点来看每次任务计算的耗时是10S，这里差不多有80次的任务都已经执行完毕了，还有大概20个任务正在计算中，也就是对应还有200MB的对象在引用着，这部分对象是不会被回收的，而我们的幸存者区域最大也就是150MB无法存放下200MB，那么根据我们讲过的空间担保机制，这200MB对象会直接进入到老年代！

image

由于每一分钟就会将Eden区填满触发Minor GC，也就是每分钟就会有200MB对象进入到老年代，那当老年代的内存占用的越多后会发生什么事情呢？比如两分钟过去了，这时占用400MB，那老年代可用空间就只剩1.1G了，那第三分钟触发Minor GC的时候，一判断发现，老年代剩余空间已小于Eden区所有对象1.2G大小了，则会走另一条分支的判断了，我们可以根据下图再来回顾下：

image

先看参数：-XX：-HandlePromotionFailure是否设置，当然一般都会设置，此时会判断老年代连续空间是否大于历史平均晋升老年代对象的大小，那历史晋升对象大小都在200MB，很明显大于，那么JVM会直接进行冒险操作，触发Minor GC的执行，而本次冒险是成功的！新生代依然继续晋升200MB对象到老年代。

那么当系统运行到第7分钟的时候，这时进入到老年代的对象有1.4G了，剩余空间仅剩100MB！如下图：

image

系统运行到这儿，发现老年代剩余空间已经比历史平均晋升对象大小都要小了，这时会直接触发Full GC！假设老年代空间都可以被回收，那么这时老年代对象就完全清除，接着会继续进行Minor GC，200MB对象继续进入老年代，又开始重复循环执行了。

那么按照以上的运行分析，我们可以得出一个结论就是：系统平均运行7、8分钟左右就会触发一次Full GC的执行！而每次一旦Full GC执行，就会严重影响到系统的运行效率，加上该系统的Full GC频率较高，给用户带来的使用感受是非常糟糕的！

4.JVM优化

像真实开发中大家也有很大几率会遇到类似这样的情况，我们应该减少Full GC的次数以及降低它出现的频率，甚至不触发Full GC，那么如何进行优化呢？这也是考验一个Java程序员的价值体现。

针对类似的计算系统，每次Minor GC的时候，必然会有一部分数据没处理完毕，但是按照现有的内存模型，我们的幸存者区域只有150MB是无法满足200MB对象的存放，因此有必要调整我们的内存比例。

解决方案：

3GB的堆内存大小，我们直接分配2G给新生代，1G给老年代，这样Survivor区的大小就有200MB了每次刚好能存放下MinorGC过后存活的对象了。如下图所示：

image

只要每次Minor GC时200MB存活对象可以存放进Survivor区，那么等下一次Minor GC时这部分对象对应的计算任务也已经结束，也可以直接进行回收。

那么接下来我们还是在继续模拟跑一次，当Eden区内存已经装满，此时S0区也有200MB对象，这是触发Minor GC的执行，200MB正在执行的任务对象（存活对象）直接转移到S1区，回收清空掉Eden区和S0区，如下图：

image

那么通过以上的分析也不免看出，基本上很少会有对象进入到老年代，我们也成功的将几分钟一次的Full GC降低到几个小时一次，大幅度提升了系统的性能，避免了Full GC对系统运行的影响！

当然这里其实还有一个细节点：就是动态年龄对象规则！如果在Survivor空间中相同年龄所有对象大小的总和大于Survivor空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到-XX：MaxTenuringThreshold中要求的年龄。这里需要结合自己公司的实际系统分析到底有多少对象是根据动态年龄规则进入到了老年代，如果要避免因为这项规则进入老年代，从而触发Full GC也可以尝试调整Eden区和Survivor区的比例，调整survivor区的大小。