线上的老年代频繁Full GC的案例,理解:

  • 整个对象分配以及转移到老年代
  • Minor GC和Full GC过程

案例

某数据计算系统,日处理数据量在上亿的规模。系统会不断从MySQL及其他数据源提取大量数据,加载到自己的JVM内存进行计算处理:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器

这数据计算系统不停通过SQL语句和其他方式从各种数据存储中提取数据到内存中来进行计算,大致当时的生产负载是每分钟大概需要执行500次数据提取和计算的任务。 但这是一套分布式运行的系统,所以生产环境部署了多台机器,每台机器大概每分钟负责执行100次数据提取和计算的任务。 每次会提取大概1万条左右的数据到内存里来计算,平均每次计算大概需要耗费10s。 然后每台机器是4核8G的配置,JVM内存给了4G,其中新生代和老年代分别是1.5G的内存空间: #yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_老年代_02

该系统到底多块会塞满新生代?

既然这个系统每台机器上部署的实例,每分钟会执行100次数据计算任务,每次是1万条数据需要计算10秒的时间,那每次1万条数据大概会占多大内存? 这里每条数据都较大,大概每条数据包含平均20个字段,可认为平均每条数据在1KB左右。那每次计算任务的1万条数据就对应了10MB的大小。 若新生代按8:1:1分配Eden和两块Survivor区域,那Eden=1.2GB,每块Survivor=100MB:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_03

按此内存,每次执行一个计算任务,就会在Eden分配10MB左右对象,那一分钟大概对应100次计算任务。基本上一分钟过后,Eden区里就满了。所以新生代里的Eden区,基本上1min左右就满了。

触发Minor GC时,会有多少对象进入老年代?

假设新生代Eden在1min后满了,然后接着继续执行计算任务时,必然导致需要进行Minor GC,回收一部分垃圾对象。执行Minor GC之前会先进行检查: 第一步,老年代可用内存>新生代全部对象? 此时老年代空,有1.5G可用内存,新生代Eden大概算做有1.2G对象。

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_04

此时,即使一次Minor GC,全部对象都存活,老年代也能放下,则此时就会直接执行Minor GC。

那此时Eden有多少对象存活,无法被GC呢?

每个计算任务1万条数据,需计算10s,假设此时80个计算任务都执行结束,但还有20个计算任务共计200MB数据还在计算,此时就是200MB对象是存活的,不能被GC,然后有1G对象可GC:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_老年代_05

此时一次Minor GC就会回收1G对象,然后200M对象能放入Survivor区吗?

不能!因为任一块Survivor区实际上就100M空间,此时就会通过空间担保机制,让这200MB对象直接进入老年代,占用里面200MB内存空间,然后Eden区清空:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_06

系统运行多久,老年代大概就会填满?

这系统大概运行多久,老年代会填满?按上述计算,每min都是个轮回,大概就是每min都会把新生代Eden填满,然后触发一次Minor GC,然后大概都会有200MB数据进入老年代。 若2min过去了,此时老年代有400M被占用,只有1.1G可用,若第3分钟运行完毕,又要进行Minor GC,会做什么检查呢?

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_老年代_07

  1. 先检查老年代可用空间 > 新生代全部对象?

此时老年代可用空间1.1GB,新生代对象有1.2GB,此时假设一次Minor GC过后新生代对象全部存活,老年代是放不下的,就得看“-XX:-HandlePromotionFailure”参数,一般都会打开 此时会进入第二步检查

  1. 老年代可用空间 > 历次Minor GC过后进入老年代的对象的平均大小

大概每min执行一次Minor GC,每次大概200M对象进入老年代。那此时发现老年代1.1G,大于每次Minor GC后平均的200M。所以本次Minor GC后大概率还是有200MB对象进入老年代,1.1G可用空间足够。所以此时就会放心执行一次Minor GC,然后又是200MB对象进入老年代。 转折点大概在运行了7min后,7次Minor GC后,大概1.4G对象进入老年代,老年代剩余空间就不到100MB ,几乎快满:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_数据_08

系统运行多久,老年代会触发1次Full GC?

大概在第8min运行结束时,新生代又满,执行Minor GC前进行检查,发现老年代只有100M,比200M小,就会直接触发一次Full GC。 Full GC会把老年代的垃圾对象都给回收,假设此时老年代被占据的1.4G全都是可回收对象,则此时一次就会把这些对象都回收:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_数据_09

然后接着就会执行Minor GC,此时Eden区情况,200MB对象再次进入老年代,之前Full GC就是为这些新生代本次Minor GC要进入老年代的对象准备:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_10

基本平均7、8分钟一次Full GC,这频率相当高。因为每次Full GC很慢, 性能很差。

如何JVM调优?

因为这数据计算系统,每次Minor GC的时候,必然会有一批数据没计算完,但按现有内存模型,最大问题是每次Survivor区放不下存活对象。 所以增加新生代内存比例,3GB堆内存,2GB分给新生代, 1GB给老年代。这样Survivor区大概200M,每次刚好能放下Minor GC后存活对象:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_老年代_11

只要每次Minor GC过后200MB存活对象可以放Survivor区域,等下次Minor GC时,这个Survivor区的对象对应的计算任务早就结束了,都可以回收。此时比如Eden区1.6G被占满,然后Survivor1有200MB上一轮 Minor GC后存活的对象:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_12

然后此时执行Minor GC,就会把Eden 1.6G对象回收,Survivor1里200MB对象也会回收,然后Eden区剩余200MB存活对象会放入Survivor2区:

#yyds干货盘点# 彻底理解对象内存分配及Minor GC和Full GC全过程_垃圾回收器_13

以此类推,基本上就很少对象会进入老年代,老年代里的对象也不会太多。 通过这个优化,成功将生产系统的老年代Full GC频率从几min一次降低到几h一次,大幅提升系统性能,避免频繁Full GC对系统性能影响。 一个动态年龄判定升入老年代的规则,若: $Survivor区中的同龄对象>超过Survivor区内存/2$ 就要直接升入老年代。所以此处优化仅是为说明:增加Survivor区大小,让Minor GC后的对象进入Survivor区中,避免进入老年代。 为避免动态年龄判定规则把Survivor区中的对象直接升入老年代,若新生代内存有限,可调整undefined- XX:SurvivorRatio=8undefined参数:默认Eden区比例80%,也可降低Eden区比例,给两块Survivor区更多内存空间,然后让每次Minor GC后的对象进入Survivor区中,还可避免动态年龄判定规则直接把他们送入老年代。

垃圾回收器

在新生代和老年代进行垃圾回收的时候,都是要用垃圾回收器进行回收的,不同的区域用不同的垃圾回收器。

Serial和Serial Old垃圾回收器:分别用来回收新生代和老年代的垃圾对象 工作原理就是单线程运行,垃圾回收的时候会停止我们自己写的系统的其他工作线程,让我们系统直接卡死不动,然后让他们垃圾回收,这个现在一般写后台Java系统几乎不用。

ParNew和CMS垃圾回收器:ParNew现在一般都是用在新生代的垃圾回收器,CMS是用在老年代的垃圾回收器,他们都是多线程并发的机制,性能更好,现在一般是线上生产系统的标配组合。下周会着重分析这两个垃圾回收器。

G1垃圾回收器:统一收集新生代 和老年代,采用了更加优秀的算法和设计机制,是下下周的重点,一周都会来分析G1垃圾回收器的工作原理和优缺点。