公司项目升级到Spring 5.3.x之后,GC次数急剧增加,我TM人傻了

本文讲述了在项目升级到Spring 5.3.x后,GC次数增加的问题。通过jmap和JFR+JMC进行定位,发现BeanUtils.copyProperties方法在新版本中创建大量ResolvableType对象导致内存消耗。通过查看源码和实验验证,确认了问题原因,并提出了使用BeanCopier作为替代方案来解决问题。
摘要由CSDN通过智能技术生成

问题背景

最近我们的项目升级到了 Spring Boot 2.4.6 + Spring Cloud 2020.0.x,但是升级后,我们发现 YoungGC 明显增高,分配对象速率明显增高,但是晋升的对象并没有增多,证明都是新创建的对象并且没过多久就可以被回收。我们来看其中一个进程的监控,这时候的 http 请求速率大概在 100 左右:

公司项目升级到Spring 5.3.x之后,GC次数急剧增加,我TM人傻了

这就很奇怪了,请求速率并没有那么大,但是通过监控可以看出每秒钟分配了将近两个 G 的内存。在升级之前,这个分配速率大概在 100~200 MB 左右,在同等请求速率下。那么这多出来的内存究竟是从哪里消耗的呢?

定位方式

我们需要看一下内存中各种对象的统计数据,即使用 jmap 命令。同时不能只查看存活对象的统计,因为从监控中看出来并不是老年代对象过多,因为晋升的对象并没有增多,相反的,我们如果我们能排除现在还存活的对象就更好了。同时,由于 GC 相当频繁,1s 左右就会有一次。所以基本不能期望一次就能抓到我们想要的 jmap。同时 jmap 因此导致所有线程进入 safepoint 从而 STW,对线上有一定影响,所以不能太频繁 jmap。所以,我们采取如下策略:

  1. 扩容一个实例,之后将一个实例,通过注册中心以及限流器将某个实例的流量切走一半;
  2. 针对这个实例,连续执行 jmap -histo(统计所有对象) 以及 jmap -histo:live(仅统计存活对象);
  3. 重复第二步 5 次,每次间隔 100ms,300ms,500ms,700ms;
  4. 去掉限流这个实例的限流,将新扩容的实例关闭。

通过这几次的 jmap 对比,我们发现 jmap 统计中排在前面的对象类型有一个 spring 框架的:

 num     #instances         #bytes  class name (module)
-------------------------------------------------------
   
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值