线上环境频繁GC问题排查,Finalizer对象该背这个锅吗？

最新推荐文章于 2025-04-16 16:49:56 发布

原创

最新推荐文章于 2025-04-16 16:49:56 发布 · 1.6k 阅读

3 ·

CC 4.0 BY-SA版权

文章标签：

#java #jvm

本文详细描述了一个SpringMVC服务遭遇频繁GC问题的排查过程。通过Arthas工具分析，发现大量Finalizer对象占用堆内存，主要由频繁创建的HttpsURLConnection对象引起。由于这些对象重写了finalize()方法，导致它们进入ReferenceQueue等待低优先级的Finalizer线程回收。为解决此问题，服务引入了HttpClient的连接池，有效减少了Finalizer对象的生成，从而显著降低了GC频率。总结强调了线上环境性能监控的重要性以及问题解决的经验和技巧。

问题描述

公司的一个SpringMVC服务，最近在做运维检查的时候发现young gc 和 full gc太频繁，远远超过了正常情况。服务器配置是4核8G，该服务分配了6G内存。通过arthas的dashboard统计情况在20个小时之内发生的young gc和 full gc 次数，如下图：young gc 393次，full gc 19次
在这里插入图片描述

问题排查

在eden区达到80%的时候，通过arthas 的 heapdump dupm了堆内存文件

java -jar arthas-boot.jar
挂载对应的应用的PID,进入到arthas管理界面
heapdump /tmp/dump.hprof

使用MemoryAnalyzer 分析hprof 文件，发现heap中存在最多的对象就是java.lang.ref.Finalizer 对象，占用了整个空间的47%，如下图
点击Histogram 查看Finalizer对象，右键—>List Objects—> with outgoing reference 查看具体的Finalizer对象，查看图片左下角的referent 就是真正需要回收的垃圾。分析了一部分referent 都是涉及到底层jdk 关于https请求连接的对象。如HtppsURLConnectionIpml,ZipFileInpu