一次JVM中FullGC问题排查过程

最新推荐文章于 2025-05-29 12:46:34 发布
原创 最新推荐文章于 2025-05-29 12:46:34 发布 · 1.6k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

本文记录了一次JVM频繁触发FullGC的排查过程，通过日志分析发现平均三秒发生一次FullGC，并在重启应用后观察到Perm区不断上涨。使用Btrace工具定位到HSF类加载导致的类定义，发现Perm区配置过小（128M）。解决方案包括增大 Perm 区大小至256M以及优化jar包依赖以减少无用的类加载。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

这个问题比较常见，我把过程中的日志记录下来了，希望后续大家遇到类似的能快速定位。

1、平均三秒一次FullFC

 sudo -u admin java/bin/jstat -gcutil `pgrep java -u admin` 1000 2000

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  

  0.00   0.53  71.69   9.19  92.42   6183  901.265 54986 48865.327 49766.592

  0.00   0.53  72.34   9.19  92.42   6183  901.265 54986 48866.617 49767.881

  0.00   0.53  72.68   9.19  92.42   6183  901.265 54986 48866.617 49767.881

  0.00   0.53  73.08   9.19  92.42   6183  901.265 54987 48866.617 49767.881

  0.00   0.53  73.08   9.19  92.42   6183  901.265 54987 48866.617 49767.881

  0.00   0.53  73.68   9.19  92.42   6183  901.265 54987 48867.875 49769.140

  0.00   0.53  73.87   9.19  92.42   6183  901.265 54988 48867.875 49769.140

  0.00   0.53  73.87   9.19  92.42   6183  901.265 54988 48869.260 49770.525

  0.00   0.53  74.90   9.19  92.42   6183  901.265 54988 48869.260 49770.525

  0.00   0.53  75.32   9.19  92.42   6183  901.265 54988 48869.260 49770.525

  0.00   0.53  75.39   9.19  92.42   6183  901.265 54989 48869.260 49770.525

  0.00   0.53  76.07   9.19  92.42   6183  901.265 54989 48870.539 49771.804

  0.00   0.53  76.34   9.19  92.42   6183  901.265 54990 48870.539 49771.804

  0.00   0.53  76.34   9.19  92.42   6183  901.265 54990 48870.539 49771.804

  0.00   0.53  77.36   9.19  92.42   6183  901.265 54990 48871.973 49773.238

  0.00   0.53  77.65   9.19  92.42   6183  901.265 54990 48871.973 49773.238

  0.00   0.53  77.76   9.19  92.42   6183  901.265 54991 48871.973 49773.238

 

2、重启应用之后发现Perm区一直在上涨

 sudo -u admin /java/bin/jstat -gcutil `pgrep java -u admin` 5000 200

  S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT  

  0.00  71.04  14.28   0.00  71.46      5    0.467     0    0.000    0.467

  0.00  71.04  16.19   0.00  71.47      5    0.467     0    0.000    0.467

  0.00  71.04  18.30   0.00  71.54      5    0.467     0    0.000    0.467

  0.00  71.04  20.82   0.00  71.54      5    0.467     0    0.000    0.467

  0.00  71.04  22.77   0.00  71.54      5    0.467     0    0.000    0.467

  0.00  71.04  24.46   0.00  71.54      5    0.467     0    0.000    0.467

  0.00  71.04  26.24   0.00  71.54      5    0.467     0    0.000    0.467

  0.00  71.04  29.01   0.00  72.66      5    0.467     0    0.000    0.467

  0.00  71.04  30.84   0.00  72.66      5    0.467     0    0.000    0.467

  0.00  71.04  32.65   0.00  72.68      5    0.467     0    0.000    0.467

  0.00  71.04  34.48   0.00  72.68      5    0.467     0    0.000    0.467

  0.00  71.04  36.40   0.00  72.69      5    0.467     0    0.000    0.467

  0.00  71.04  38.10   0.00  72.69      5    0.467     0    0.000    0.467

  0.00  71.04  39.76   0.00  72.70      5    0.467     0    0.000    0.467

 

3、Btrace查看后发现HSF的一个类在调用ClassLoader的defineClass方法来创建类：

sudo -u admin sh  btrace -cp /home/admin/btrace/build 4955  /home/admin/btrace/BtraceAll.java

===========================================================================

java.lang.ClassLoader.defineClass

Time taken : 2

java thread method trace:---------------------------------------------------

java.lang.ClassLoader.defineClass(ClassLoader.java:615)

org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.defineClass(DefaultClassLoader.java:165)

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.defineClass(ClasspathManager.java:554)

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findClassImpl(ClasspathManager.java:524)

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClassImpl(ClasspathManager.java:455)

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass_LockClassLoader(ClasspathManager.java:443)

org.eclipse.osgi.baseadaptor.loader.ClasspathManager.findLocalClass(ClasspathManager.java:423)

org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.findLocalClass(DefaultClassLoader.java:193)

org.eclipse.osgi.framework.internal.core.BundleLoader.findLocalClass(BundleLoader.java:368)

org.eclipse.osgi.framework.internal.core.SingleSourcePackage.loadClass(SingleSourcePackage.java:33)

org.eclipse.osgi.framework.internal.core.BundleLoader.findClassInternal(BundleLoader.java:432)

org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:397)

org.eclipse.osgi.framework.internal.core.BundleLoader.findClass(BundleLoader.java:385)

org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:87)

java.lang.ClassLoader.loadClass(ClassLoader.java:247)

com.taobao.hsf.rpc.tbremoting.provider.ProviderProcessor.handleRequest(ProviderProcessor.java:117)

com.taobao.hsf.rpc.tbremoting.provider.ProviderProcessor.handleRequest(ProviderProcessor.java:55)

com.taobao.remoting.impl.DefaultMsgListener$1.run(DefaultMsgListener.java:98)

java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

java.lang.Thread.run(Thread.java:662)

 

4、Perm区配置都是128M，有点小，之前占比90%的时候开始FullGC

VM Flags:

-Dprogram.name=run.sh -Xms4g -Xmx4g -XX:PermSize=128m -XX:MaxPermSize=128m -Xmn2500m -XX:SurvivorRatio=7 -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

 

5、应用中war包的lib目录就有177M

在应用刚开始启动的时候，占比70% 左右，也就是90M左右的样子，之后有些类动态加载进来了，到90% 后就回收不了了。

 

临时解决办法：调大Perm区，增大至256m

后续考虑：优化jar包依赖，目前太多没用的被依赖进来，导致包很大。

 

JVM FullGC问题剖析全过程（原创）
DanielAntony的博客
09-10 2914
  1. 背景 偶然发现查看线上日志-Xloggc:******/gc.log下面的日志，发现线上机器存在Full GC，查找其他服务发现都会有这个问题， 基于我们系统很多垃圾回收机制都是ParalllelGC，即吞吐量优先GC方式，GC线上在处理任务时会造成系统stop the wrold暂停，而且GC 时间相对CMS等收集器而已要更长，虽然这些Full GC暂时无明显停顿，但是出于优化...
深入探究 JVM 频繁 Full GC 的排查过程
fudaihb的博客
02-23 2997
在当今软件开发领域，Java语言以其跨平台性、面向对象、高性能等特点成为了广泛应用的首选之一。而Java应用程序的核心执行环境就是Java虚拟机（JVM），它负责将Java字节码翻译成机器码并执行，是Java程序运行的基础。在JVM的内存管理机制中，垃圾回收（GC）是一个至关重要的部分，负责释放不再被引用的对象占用的内存空间，以确保应用程序的稳定性和性能。
JVM Full GC 频繁问题排查、优化及解决方案
最新发布
weixin_56018532的博客
05-29 1980
JVM频繁Full GC问题是Java应用性能调优中常见且重要的挑战。本文系统地分析了导致频繁Full GC的各种原因，包括内存泄漏、高并发、大对象分配、内存碎片化等，并提供了详细的排查方法和优化建议。JVM参数调优：合理配置堆内存大小、分代比例、垃圾收集器等参数，使其适合应用特性。代码层面优化：减少不必要的对象创建，避免内存泄漏，优化数据结构和算法，合理管理资源。架构层面优化：实现流量控制，优化线程模型，改进数据处理方式，提高系统整体效率。监控与预警：建立完善的监控体系，及时发现潜在问题，防患于未然。
记一次FullGC排查过程
八角塘塘主的博客
04-15 2827
因为使用占用到100%,就很明显了。
Full GC 的深度解析与排查流程详解
qw2869534823的博客
03-22 1479
Full GC（Full Garbage Collection，全量垃圾回收）​是 JVM 垃圾回收机制中最彻底、最耗时的回收过程​Full GC 的本质：JVM 内存管理的最后防线，但频繁 Full GC 是系统危险的信号。​排查流程：导出堆转储 → MAT 分析 → 代码修复。​终极目标：减少 Full GC 频率（通过参数调优）和耗时（通过代码优化）。参考：腾讯元宝。
FullGC问题排查
Yheaw的博客
05-11 346
FullGC问题排查
一次诡异的full gc查找问题全过程
08-26
在本篇文章中，我们将分享一个 Full GC 问题排查过程，通过示例代码和实际操作，介绍了如何快速定位 Full GC 问题的原因和解决方案。 问题描述 在我们的服务中，突然出现了频繁的 Full GC 问题，而服务本身没有...
一次Jvm old过高的排查过程实战记录
08-26
"Jvm Old区过高排查过程...在这篇文章中，我们探索了Jvm Old区过高的排查过程，了解了Jvm的内存结构和垃圾回收机制，并使用jstat、jmap和jvisualvm工具来分析Jvm的内存情况，最后发现了Jvm Old区过高的原因和解决方案。
线上问题——频繁 Full GC 问题的排查思路
longool的博客
12-21 1568
启用 GC 日志分析 GC 日志内容选择合适的垃圾回收器调整垃圾回收器参数实时监控内存使用情况分析监控数据
一次 JVM FullGC 的排查过程及解决方案！
mifffy_java的博客
06-12 4954
1、问题产生 最近新上线的系统偶尔会报FullGC时间过长（>1s）的告警，查看GC日志，如下图所示： 看到GC日志，我第一时间关注到的不是GC耗时，而是GC触发的原因：Metadata GC Threshold 也就是 FullGC 触发的原因是因为Metaspace大小达到了GC阈值。在监控系统里面看了一下Metaspace的大小变化趋势，如下图所示： 按照以往的经验，M...
记一次频繁FullGC排查过程
Gzzz的博客
08-19 1756
记一次频繁FullGC排查过程 1.首先通过top命令查看CPU占用情况，发现CPU占用并不高。 2.用jstat -gcutil PID 1000查看内存回收情况，可以看到FGC次数很多并且很频繁。 3.通过jmap -dump:format=b,file=heapdump.hprof PID生成堆转储快照dump文件。 4.使用jmap -heap PID查看j进程堆信息以及垃圾回收算法等 。
生产问题（十八）FullGC排查
m0_69270256的博客
08-15 883
最近服务发生fullgc，响应时长大幅增长
(转）FULL GC分析过程分享
akingde
01-22 233
    http://www.taobaotest.com/blogs/2294 在性能测试过程中,FULL GC频繁是比较常见的问题，FULL GC 产生的原因有很多，这里主要针对meta压测过程中分析FULL GC问题的一些思路进行分享，供大家参考 1.如何发现是否发生FULL GC和FULL GC是否频繁 使用JDK自带的轻量级小工具jstat 语法结构： Usage: jstat...
full gc排查思路
山楂片的博客
05-12 4259
清楚排查问题时能使用哪些工具 公司的监控系统：大部分公司都会有，可全方位监控JVM的各项指标。 JDK的自带工具，包括jmap、jstat等常用命令： 查看堆内存各区域的使用率以及GC情况 jstat -gcutil -h20 pid 1000 查看堆内存中的存活对象，并按空间排序 jmap -histo pid | head -n20 dump堆内存文件 jmap -dump:format=b,file=heap pid ...
频繁的Full GC的问题排查
所有文章都可以查看。如果发现需要VIP才能看的文章，请留言，可能是发布的时候手抖了。
05-01 6700
Full GC没有明确的官方定义，有人认为需要对JVM能够用到的所有共享内存(堆、元空间/永久代、直接内存)进行GC才是Full GC；有人认为只要对整个堆进行了GC(新生代GC+老年代GC)就算是Full GC。在jatat命令的输出中，FGC表示老年代GC，个人倾向于第二种说法。
频繁 Full GC 问题排查方法
m0_57836225的博客
09-26 808
平时同学们可以总结一套自己解决频繁 Full GC 问题的方法步骤，以便在面试时对答如流，给面试官留下好印象。希望本文总结的通用步骤能为大家提供参考。
频繁Full GC如何排查
Gemini1995的博客
03-13 2431
频繁的Full GC可能会影响应用程序的性能和稳定性，因此需要进行排查和解决。通过以上方法可以逐步排查和解决频繁Full GC的问题，提高应用程序的性能和稳定性。
彻底理解对象内存分配及Minor GC和Full GC全过程
JavaEdge全是干货的技术号
01-16 2658
彻底理解对象内存分配及Minor GC和Full GC全过程 线上的老年代频繁Full GC的案例，理解： 整个对象分配以及转移到老年代 Minor GC和Full GC过程 案例 某数据计算系统，日处理数据量在上亿的规模。系统会不断从MySQL及其他数据源提取大量数据，加载到自己的JVM内存进行计算处理： [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nh0UrmXJ-1642342394970)(https://dispatcher-upload.bj.bcebos.
JVM故障排查：MAT工具与Full GC分析
"本文主要介绍了如何使用MAT工具进行JVM Full GC分析，以及在Java进程中进行内存管理和诊断的常用命令。" 在Java开发过程中，内存管理是关键环节，特别是当出现`OutOfMemoryError`或者系统异常如负载过高、IO异常、...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值