本文通过一个日处理上亿数据的计算系统案例，探讨了如何定位和解决频繁Full GC问题。系统每分钟执行100次数据计算任务，导致新生代快速填满，触发Minor GC并使大量对象进入老年代，最终引发频繁Full GC。通过调整JVM参数，增大新生代和Survivor区的内存比例，有效减少了对象进入老年代，从而显著降低了Full GC的频率，提高了系统性能。
添加VX：ruyuan0220，回复：CSDN，领取更多精品学习资料！
目录
一个日处理上亿数据的计算系统
先给大家说一下这个系统的案例背景，当时我们团队里自己研发的一个数据计算系统，日处理数据量在上亿的规模。
为了方便大家集中注意力理解这个系统的生产环境的JVM相关的东西，所以对系统本身就简化说明了。
简单来说，这个系统就是会不停的从MySQL数据库以及其他数据源里提取大量的数据加载到自己的JVM内存里来进行计算处理，如下图所示。
这个数据计算系统会不停的通过SQL语句和其他方式从各种数据存储中提取数据到内存中来进行计算，大致当时的生产负载是每分钟大概需要执行500次数据提取和计算的任务。
但这是一套分布式运行的系统，所以生产环境部署了多台机器，每台机器大概每分钟负责执行100次数据提取和计算的任务。
每次会提取大概1万条左右的数据到内存里来计算，平均每次计算大概需要耗费10秒左右的时间
然后每台机器是4核8G的配置，JVM内存给了4G，其中新生代和老年代分别是1.5G的内存空间，大家看下图。
这个系统到底多快会塞满新生代？
现在明确了一些核心数据，接着我们来看看这个系统到底多快会塞满新生代的内存空间？
既然这个系统每台机器上部署的实例，每分钟会执行100次数据计算任务，每次是1万条数据需要计算10秒的时间，那么我们来看看每次1万条数据大概会占用多大的内存空间？
这里每条数据都是比较大的，大概每条数据包含了平均20个字段，可以认为平均每条数据在1KB左右的大小。
那么每次计算任务的1万条数据就对应了10MB的大小。所以大家此时可以思考一下，如果新生代是按照8:1:1的比例来分配Eden和两块Survivor的区域，那么大体上来说，Eden区就是1.2GB，每块Survivor区域在100MB左右，如下图。
基本上按照这个内存大小而言，大家会发现，每次执行一个计算任务，就会在Eden区里分配10MB左右的对象
一分钟大概对应100次计算任务，基本上一分钟过后，Eden区里就全是对象，基本就全满了。
所以说，回答这个小节的问题，新生代里的Eden区，基本上1分钟左右就迅速填满了。
触发Minor GC的时候会有多少对象进入老年代？
此时假设新生代的Eden区在1分钟过后都塞满对象了，然后在接着继续执行计算任务的时候，势必会导致需要进行Minor GC回收一部分的垃圾对象。
这里在执行Minor GC之前会先进行的检查。
首先第一步，先看看老年代的可用内存空间是否大于新生代全部对象？
看下图，此时老年代是空的，大概有1.5G的可用内存空间，新生代的Eden区大概算他有1.2G的对象好了。
最低0.47元/天 解锁文章
扫一扫
778
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
