AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

线上频繁fullgc问题-SpringActuator的坑

2024-06-04 115
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
简介： 偷偷开启的监控在吃内存

原文首发于博客园：https://www.cnblogs.com/qisi/p/-/gc_spring_meter

整体复盘：

一个不算普通的周五中午，同事收到了大量了cpu异常的报警。根据报警表现和通过arthas查看，很明显的问题就是内存不足，疯狂无效gc。而且结合arthas和gc日志查看，老年代打满了，gc不了一点。既然问题是内存问题，那么老样子，通过jmap和heap dump 文件分析。
不感兴趣的可以直接看结论

  1. 通过jmap命令查看的类似下图，并没有项目中明显的自定义类，而占空间最大的又是char数组，当时线上占900M左右，整个老年代也就1.8个G；此时dump文件同事还在下载，网速较慢。
    image.png

  2. 通过业务日志查看，很多restTempalte请求报错，根据报错信息可知是某xx认证过期了，导致接收到回调，业务处理时调接口报错了；查询数据库，大概有20多万回调。根据过期时间和内存监控，大概能对的上号，表明内存异常和这个认证过期有关。怀疑度最高的只有回调以及回调补偿任务，但是一行一行代码看过去，并不觉得有什么异常。

    下载完dump文件后，先重启了服务器，避免影响业务，然后着手分析文件。

  3. 在dump文件下载完之后，使用jvisualvm分析，最多的char里大部分都是一些请求的路径，如“example/test/1"，”“example/test/2"之类的，都是接口统一，但是参数不一样，因为是GET请求，所以实际路径都不一样。Jvisualvm点击gc_root又一直计算不出来，在等待计算的过程中，一度走了弯路
    image.png

    于是又现下载jprofiler，通过jprofiler的聚类，确定了一定是这个Meter导致的，而通过JProfile的分析，终于定位到是
    org.springframework.boot.actuate.metrics.web.client.MetricsClientHttpRequestInterceptor#intercept这个类。然后发现，MetricsClientHttpRequestInterceptor 持有一个meterRegistry，里面核心是个map，所以是map没有清除。根据依赖分析，发现是有次需求引入了redisson-spring-boot-starter，而redisson依赖了spring-boot-starter-actuator，这东西默认启动了，会拦截所有的RestTempalte请求，然后记录一些指标。
    image.png
    image.png

所以问题变成了，为什么map没有清掉已经执行完的请求？
我之前并没有研究过spring的actuator，只是看过skywalking的流程，所以我以为也和skywalking一样，记录然后上报，上报之后删除本地的。所以当时怀疑，难道是和我们请求都异常了有关，但是正如下面的代码，无论是否异常，都是执行finnally，所以又不太可能。

ClientHttpResponse response = null;
try {
   response = execution.execute(request, body);
   return response;
}
finally {
   try {
      getTimeBuilder(request, response).register(this.meterRegistry).record(System.nanoTime() - startTime,
            TimeUnit.NANOSECONDS);
   }
   catch (Exception ex) {
      logger.info("Failed to record metrics.", ex);
   }
   if (urlTemplate.get().isEmpty()) {
      urlTemplate.remove();
   }
}

而在我自己尝试复现之后，meterRegistry的指标根本不会被自动清除，生命周期和应用的生命周期一样。因为并不存在上报，数据全部在内存（虽然可以导出到数据库，但并没有深入研究）。其实也合理，因为如果要通过Grafana等可视化平台查看的时候，我们也希望查看任意时刻的监控。而且其有一个属性是maxUriTags，默认值是100，其作用是限制meterMap里uri的个数，理论上并不会记录太多。

结论

所以到此为止，可以定结论，那就是因为引入了redisson-spring-boot-starter，导致不知情引入了spring-boot-starter-actuator。
因此默认开启了http.client.request指标的监控，关于http.client.request，有一个属性是maxUriTags，默认值是100，其作用是限制meterMap里uri的个数。但是maxUriTags起作用的地方MeterFilter没有生效。
由于maxUriTags没有生效，导致监控信息里的uri因为业务大量的GET请求中存在唯一id，本身就很占内存。压死内存的最后稻草是认证过期和补偿任务。补偿任务为保证及时性一直在频繁执行，而接口的uri里两个变量（token和uniId）导致meterMap里的key不重复，一直在插入，20万回调，token两小时更新一次，持续了两天，最终产生了124万条字符串，被map持有，无法回收。

解决方案

  1. 不需要监控
    直接排除掉spring-boot-starter-actuator
  2. 需要监控但不需要http.client.request指标
     management:
   metrics:
     web:
       client:
         request:
           autotime:
             enabled: false
  3. 需要http.client.request指标
    jar包升到2.5.1或以上
     <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-actuator-autoconfigure</artifactId>
     <version>2.5.1</version>
 </dependency>

复现：

新建测试项目
image.png

相关代码和配置如下

@SpringBootApplication
@Slf4j
public class Application {
    public static void main(String[] args) {
        ConfigurableApplicationContext run = SpringApplication.run(Application.class);
        RestTemplate bean = run.getBean(RestTemplate.class);
        for (int i = 0; i < 300000; i++) {
            try {
                String forObject = bean.getForObject("http://localhost:9999/first/echo?i="+i, String.class);
            }catch (Exception e){
                log.error("执行"+i+"次");
            }
        }
    }
}

@Configuration
public class RestTemplateTestConfig {
    @Bean
    public RestTemplate restTemplate(RestTemplateBuilder builder){
        return builder.build();
    }
}

<dependencies>
    <dependency>
        <groupId>org.redisson</groupId>
        <artifactId>redisson-spring-boot-starter</artifactId>
        <version>3.13.1</version>
    </dependency>
    <dependency>
        <groupId>org.apache.httpcomponents</groupId>
        <artifactId>httpclient</artifactId>
    </dependency>
</dependencies>

server:
  port: 8080
spring:
  redis:
    host: ************
    password: **********
#management:
#  endpoints:
#    web:
#      exposure:
#        include: "metrics"
#  metrics:
#    web:
#      client:
#        request:
#          autotime:
#            enabled: false

启动项目通过jconsole查看整个堆的监控和老年代监控分别如下，可以看出老年代一直在增长，并不会回收
image.png
image.png

甚至手动触发GC，老年代也回收不了

[Full GC (System.gc()) [Tenured: 195217K->195457K(204800K), 0.3975261 secs] 233021K->195457K(296960K), [Metaspace: 30823K->30823K(33152K)], 0.3976223 secs] [Times: user=0.39 sys=0.00, real=0.40 secs]

通过jprofiler确定主要是meterMap占据内存了，最多的都是字符串。
image.png
image.png

分析

actuator导致rest启动了metrics记录
在使用RestTemplateBuilder构建RestTemplate的时候，会触发懒加载的RestTemplateAutoConfiguration里的RestTemplateBuilderConfigurer，在此期间，config中会注入RestTempalteCustomizer类型的bean。
image.png

而项目中引用了redisson-spring-boot-starter，从依赖分析可以看出间接引用了actuator相关的包。
image.png

这导致会在RestTemplateMetricsConfiguration配置类中实例化一个叫做MetricsRestTemplateCustomizer的bean，这个bean会通过上面的restTepalteBuilderConfigurer.configure方法给restTemplate添加拦截器MetricsClientHttpRequestInterceptor。
image.png

拦截器的intercept方法会在finnally中最终记录此次请求的一些指标
image.png

io.micrometer.core.instrument.Timer.Builder#register->
io.micrometer.core.instrument.MeterRegistry#time->
io.micrometer.core.instrument.MeterRegistry#registerMeterIfNecessary->
io.micrometer.core.instrument.MeterRegistry#getOrCreateMeter{
meterMap.put(mappedId, m);
}

image.png

最终存到了是SimpleMeterRegistry这个bean的meterMap中去，这个bean也是actuator-autoconfigure自动注入的
image.png

但是到目前为止，只是启动了metrics记录，假如maxUriTags有效的话，会在超过100条记录后getOrCreateMeter方法里的accept这里过滤掉，并不会走到下面的meterMap.put(mappedId, m)
image.png

为什么maxUriTags没有生效？

maxUriTags只在下图这个位置使用了，作用是构建了一个MeterFilter，根据debug我们可以确定bean是产生了的
image.png

但是在accept这里打上断点，再触发一些请求可以发现，代码并不会走到这里
image.png

往上跟，没有走到这里的情况只能是filters里没有这个MeterFilter，但我们刚才又确定metricsHttpCLientUriTagFilter这个bean是产生了的，那么就只能是没有添加到filters，也就是没有调用过meterFilter
image.png
image.png

从meterFilter往上只有可能是addFilters，一层一层往上最终到了MeterRegistryPostProcessor#postProcessAfterInitialization这个方法
image.png
image.png
image.png

我们上面说过负责记录的bean叫做simpleMeterRegistry，但是我们在这里打上条件断点发现并没有走到这里
image.png

找到SimpleMeterRegistry和MeterRegistryPostProcessor这两个bean注入的地方打断点观察，都产生了，且MeterRegistryPostProcessor比SimpleMeterRegistry产生的要早
image.png
image.png

理论上没问题，但现在确实没走到，所以只能在SimpleMeterRegistry产生的时候在org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory#applyBeanPostProcessorsAfterInitialization打断点，然后可以发现，在simpleMeterRegistry实例化快结束的时候，调用后处理器时this.beanPostProcessors确实没有MeterRegistryPostProcessor
image.png
image.png

一般来说，postPorcessor的bean注入是在refresh方法的registerBeanPostProcessors中，是早于普通bean的实例化
image.png

所以simpleMeterRegistry实例化的时候没有MeterRegistryPostProcessor是不合理的情况，定位simpleMeterRegistry是何时实例化的成了关键问题

simpleMeterRegistry的实例化时机

在new SimpleMeterRegistry这里打上断点观察堆栈发现，simpleMeterRegistry是MetricsRepositoryMethodInvocationListener的参数，MetricsRepositoryMethodInvocationListener则是metricsRepositoryMethodInvocationListenerBeanPostProcessor的参数
所以是在实例化metricsRepositoryMethodInvocationListenerBeanPostProcessor这个处理器的时候，因为依赖导致先实例化了simpleMeterRegistry这个bean依赖
image.png
image.png
image.png
image.png

导致实例化了SimpleMeterRegistry，而这个时候由于没有注册，所以SimpleMeterRegistry在执行applyBeanPostProcessorsAfterInitialization时就执行不到meterRegistryPostProcessor了
image.png
image.png

spring已经修复了这个问题，spring-boot-actuator-autoconfigure版本大于2.5.0的都已经没有问题了。解决方案
2.5.1 版本中，添加了一个这个ObjectProvider，在源头上不会立即把依赖的bean初始化完
image.png
image.png

2.5.0 版本
image.png

public Object resolveDependency(DependencyDescriptor descriptor, @Nullable String requestingBeanName,
      @Nullable Set<String> autowiredBeanNames, @Nullable TypeConverter typeConverter) throws BeansException {

   descriptor.initParameterNameDiscovery(getParameterNameDiscoverer());
   if (Optional.class == descriptor.getDependencyType()) {
      return createOptionalDependency(descriptor, requestingBeanName);
   }
   //由于使用了ObjectProvider，所以这里只是返回了一个DependencyObjectProvider
   else if (ObjectFactory.class == descriptor.getDependencyType() ||
         ObjectProvider.class == descriptor.getDependencyType()) {
      return new DependencyObjectProvider(descriptor, requestingBeanName);
   }
   else if (javaxInjectProviderClass == descriptor.getDependencyType()) {
      return new Jsr330Factory().createDependencyProvider(descriptor, requestingBeanName);
   }
   else {
   //2.5.0版本中会在这个方法加载入参依赖的bean
      Object result = getAutowireCandidateResolver().getLazyResolutionProxyIfNecessary(
            descriptor, requestingBeanName);
      if (result == null) {
         result = doResolveDependency(descriptor, requestingBeanName, autowiredBeanNames, typeConverter);
      }
      return result;
   }
}
文章标签：
云数据库 Tair（兼容 Redis）
监控
Java
测试技术
Arthas
数据库
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务，基于高可靠双机热备架构及可无缝扩展的集群架构，满足高读写性能场景及容量需弹性变配的业务需求。 产品详情：https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验：数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引，您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接，领取免费ECS&amp;RDS资源，30分钟完成数据库上云实战！https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
起司
目录
相关文章
最好zzz
|
3月前
|
监控 负载均衡 算法
线程数突增！领导说再这么写就GC掉我：深入理解与优化策略
【8月更文挑战第29天】在软件开发的世界里，性能优化总是开发者们绕不开的话题。特别是当面对“线程数突增”这样的紧急情况时，更是考验着我们的技术功底和问题解决能力。今天，我们就来深入探讨这一话题，分享一些工作学习中积累的技术干货，帮助大家避免被“GC”（垃圾回收，也常用来幽默地表示“被炒鱿鱼”）的尴尬。
最好zzz
47 2
呆呆宝
|
4月前
|
Java BI 运维
开发与运维配置问题之升级机器配置后出现频繁的GC问题和超长的GC时间如何解决
开发与运维配置问题之升级机器配置后出现频繁的GC问题和超长的GC时间如何解决
呆呆宝
35 1
智物科技库
|
3月前
|
监控 JavaScript Java
JVM源码级别分析G1发生FullGC元凶的是什么
线上系统遭遇频繁Old GC问题，监控显示出现多次“to-space exhausted”日志，这表明垃圾回收过程中因年轻代 Survivor 区或老年代空间不足导致对象晋升失败。通过 JVM 源码分析，此问题源于对象转移至老年代失败时，JVM 无法找到足够的空间存放存活对象。进一步排查发现大对象分配占用了预留空间，加剧了空间不足的情况。使用 JFR 分析工具定位到定期报表序列化导致大量大对象生成，通过改用堆外内存进行序列化输出，最终解决了频繁 Old GC 问题。
智物科技库
117 0
香吧香
|
4月前
|
监控 Java 中间件
FGC频繁导致CPU 飙升定位及JVM配置优化总结
FGC频繁导致CPU 飙升定位及JVM配置优化总结
香吧香
161 0
东风微鸣技术博客
|
6月前
|
监控 前端开发 Java
案例 2: 某寿险公司核心系统 GC 开销超限问题分析
案例 2: 某寿险公司核心系统 GC 开销超限问题分析
东风微鸣技术博客
60 0
程序员jet_qi
|
SQL canal 运维
JVM第六讲：线上环境 FGC 频繁，如何解决？
JVM第六讲：线上环境 FGC 频繁，如何解决？
程序员jet_qi
293 0
翎野君
|
缓存 监控 算法
因Full GC导致CPU飙升到100%问题排查记录
因Full GC导致CPU飙升到100%问题排查记录
翎野君
339 0
javaedge
|
算法 Java 数据处理
OOM和频繁GC预防方案
这段代码明明很简单，日常跑的都没问题，怎么一大促就卡死甚至进程挂掉？大多是因为设计时，就没针对高并发、高吞吐量case考虑过内存管理。
javaedge
380 0
javaedge
|
Java
如何优化生产环境的Full GC？
大部分工程师开发完一个系统后，部署生产环境的时候往往不对JVM进行参数设置，直接用默认JVM参数，这绝对是系统负载逐渐增高的时最大问题 如你不设置-Xmx、-Xms之类的堆内存大小，你启动一个系统，可能默认就给你几百MB的堆内存大小，新生代和老年代可能都是几百M。
javaedge
166 0
我想问问天
|
负载均衡 算法 Java
记一次线上频繁FGC的事件和解决方式
1.大量的请求，调用的地方要注意是否会导致内存的大量消耗，尽可能使用池化技术，单例等，减少创建，销毁的系统开销；2.CMS 的几个缺点，可以参考《深入java虚拟机》，对CPU占用会比较高，无法处理浮动垃圾，还有就是CMS使用的是标记-清除算法，会导致大量的空间碎片，碎片过多的话，导致分配大对象很困难，所以不得不进行FGC，也可能是这个原因导致了本文说的一直FGC的问题。
我想问问天
391 0
记一次线上频繁FGC的事件和解决方式