记一次不太成功的频繁 full gc 排查过程

上周自己负责的一个应用出现频繁full gc的问题,不得不尝试优化一下。第一次做这种事只能先看看网上的文章,然后亲自尝试怎么去完成减少full gc的频率,降低young gc的频率这一目标。虽然最终只是勉强解决了,但还是希望记录下来给下一次积攒经验。

选取了上周优化前后的两个典型工作日上午9:00到晚上9:00的GC情况。优化前一天要发生高达上10次的full gc,young gc也非常频繁。优化后的图已经没有出现full gc,young gc的频率也大大降低了,所以说基本完成目标。

接下来说明排查过程

1.jps命令查看进程id

jps是java后自带的查看虚拟机进程状态命令工具,用如下命令就可以看到虚拟机执行主类和进程ID.
jps -l

2. jmap命令导出堆转储文件

jmap是java自带的内存映像工具,能将当前应用运行内存的情况导出为文件。注意格式,file后面是导出路径,最后的数字为上一步得到的进程id。一般导出来的文件都比较大,我导出的有2.1G,而且进行分析也很耗性能,所以导出后都要传输到其它机器上进行分析,并且为了避免占用磁盘空间删除本地文件。
jmap -dump:format=b,file=kfwebHeap1016.hprof 35073

3.mat工具分析堆转储文件

mat是eclipse提供的堆转储文件分析工具,用mat打开mat上一步导出的文件,如下图所示,可以看到总体内存占用情况的扇形图,哪个文件占用内存最多就可以一目了然了。

点击histogram就可以看出各个对象的内存占用情况,如下所示

点击Leak Suspects就可以给出最有可能发生内存泄漏的几种情况。能很好的帮助用户进行内存分析,这也是mat强大的重要体现,如下:

到这里应该是最关键的环节了,可能因为没有经验,看来看去也没看出哪里不对,所以只能作罢,这条路已经走不下去了,所以说这次分析不太成功。

4.G1来了

后来向一个老同事说明了我的情况,他问我用的什么垃圾回收器,我说用的是默认的,年经代用Parallel Scavenge,老年代用Parallel Old,他说让我先换到G1试试吧。然后我查了一下,发现G1果然比较牛逼,虽然保留了以前的新生代Eden,Survivor和老年代的概念,但新生代和老年代不再物理隔离,而且它将内存分为很多等大的region,每个region根据需要都有可能成为S(Surviror),E(Eden), O(Old)的一种,所以G1既能回收新生代也能回收老年代,它以垃圾回收为第一(这也是它名字的由来:Garbage First,G1)目标,励志于取决CMS, 并且在java9是已经是jdk默认的垃圾回收器了。说了这么多,暂时没有多时间深入研究,不管怎么样还是值得一试的。于是在应用的jvm启动参数加了如下一行:
-XX:+UseG1GC
当然只是在一台机器上作了处理,也便于与其它机器作对比。

5.MetaSpace调整

通过调整后的这台机器与其它机器对比,gc情况还是改善了不少,但是在查看gc日志时发现了这么这个频繁出现的问题:
Metadata GC Threshold
由于元数据空间不足导致的GC.原来在G1中设置PermSize(永久代大小)已经没用了,取而代之的是MetaSpace参数,虽然这个用的是并非堆内存而是机器的物理内存并且最大大小没有限制,但是默认初始大小只有20m,所以要作出调整:
-XX:MetaspaceSize=128m
加了之后果然就没有出现这个问题了

6. 解决Humongous Allocation

在gc日志中还发现频繁出现:
G1 Humongous Allocation
这个是由于大型对象分配导致的问题,大型(Humongous)对象是指超过G1的Region 50%的内存对象,频繁大型对象内存内存分配会导致性能问题,而且如果一个region中大型对象过多的话则最后一个大型对内象边界和该region的边界之间的空间将不会被使用,如果有多个这样的region将会导致堆内存的碎片化,在jdk1.8u40之前这些大型对象的清理在full gc期间进行完成。较新的jvm也是把大型对象放在清理阶段,要解决上面的问题有两种方法。
1.增加region的大小(注意要在1到32m之间并且为2的整数次幂)
2.增加堆内存大小

总结:其实这一次只是引进了G1垃圾回收器并且对相关参数进行调整,但是促使我去了解jvm相关的知识和工具使用,还是有很很大收获的


作者:Acamy
链接:https://www.jianshu.com/p/900d7376b8b1

—————END—————

更多精彩:Java实战项目视频,给需要的读者,收藏!
SpringBoot 如何上传大文件?
微信支付的软件架构到底有多牛?
Java常用的几个Json库,性能强势对比!
求求你们了,别再写满屏的 if/ else 了!
基于Spring+SpringMVC+Mybatis的分布式敏捷开发系统架构(附源码)

关注公众号,查看更多优质文章
最近,整理一份Java资料《Java从0到1》,覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。获取方式:关注公众号并回复 Java 领取,更多Java内容陆续奉上。
明天见(。・ω・。)ノ♡
<think>嗯,用户想了解Java项目中频繁Full GC的现象、原因和影响。首先,我得回忆一下JVM的垃圾回收机制。根据引用[2],Full GC会清理整个堆内存,包括新生代、老年代和元空间。频繁Full GC肯定会导致应用性能下降,比如停顿时间变长,影响用户体验。 那现象方面,用户可能会注意到应用卡顿,监控工具显示Full GC次数多,内存使用率高,甚至OOM错误。比如引用[3]提到Young GC频繁导致对象进入老年代,进而触发Full GC。所以需要解释现象的时候,要结合监控数据和实际应用表现。 接下来是原因。可能的原因有很多,比如内存分配合理,老年代空间足,元空间足,代码中有内存泄漏,或者显式调用了System.gc()。引用[1]和[3]提到高并发或大数据处理导致对象快速进入老年代,Survivor区小。这时候需要分点说明每个原因的具体情况,比如大对象直接进入老年代,或者长期存活的对象积累。 然后是影响,主要涉及性能、可用性和资源成本。频繁Full GC会导致长时间的停顿,影响响应时间,甚至让用户觉得应用卡死。引用[4]强调优化GC的重要性,所以影响部分要突出对用户体验和系统稳定性的威胁。 最后,用户可能需要知道如何排查和解决这些问题。比如检查内存配置,分析GC日志,优化代码减少对象创建。引用[4]提到合理设置堆内存和GC策略,所以优化策略部分需要给出具体的建议,比如调整Survivor区比例,使用G1GC等。 还要注意用户可能没有说出来的需求,比如他们可能遇到了具体的性能问题,需要快速定位原因。所以在回答时要结构清晰,分点列出,便于用户对照检查自己的系统情况。同时,生成的相关问题要引导用户深入探讨解决方案和优化方法,帮助他们进一步学习。</think>### Java频繁Full GC的现象、原因及影响分析 #### 一、现象描述 1. **应用性能显著下降** 频繁Full GC会导致应用线程暂停(Stop-The-World),表现为接口响应时间变长、吞吐量降低,严重时可能触发超时或服务可用[^2][^4]。 2. **监控指标异常** - GC日志中`Full GC`关键字出现频率高,且单次耗时超过1秒(如`Full GC (Ergonomics) 1000ms`) - 老年代内存使用率持续接近100%,或频繁出现内存锯齿状波动[^3][^4] - 系统监控工具(如Prometheus、JVisualVM)显示堆内存无法有效回收 3. **伴随异常现象** - `OutOfMemoryError`错误频繁出现 - 容器化部署时因内存超限触发Pod重启 --- #### 二、核心原因 ##### 1. **内存分配合理** - **Survivor区过小**:Young GC后存活对象无法被Survivor区容纳,直接晋升老年代 $$ \text{晋升条件} = \text{对象年龄} > \text{MaxTenuringThreshold} \quad \text{或} \quad \text{Survivor空间足} $$ - **大对象直接分配老年代**:如未设置`-XX:PretenureSizeThreshold`,大数组或缓存对象跳过Eden区 ##### 2. **内存泄漏** - 静态集合类持有短生命周期对象 - 未关闭的数据库连接、文件流等资源 - 第三方库未正确释放Native Memory ##### 3. **GC触发条件** - **老年代空间足**:Major GC后仍无法满足新对象分配 - **元数据区溢出**:未设置`-XX:MaxMetaspaceSize`时,动态生成类过多(如Spring AOP) - **显式调用System.gc()**:未配置`-XX:+DisableExplicitGC`时可能误触发 ##### 4. **外部因素** - 高并发场景下请求量突增,瞬时产生大量临时对象 - 缓存策略当,如未设置LRU淘汰机制导致缓存膨胀 --- #### 三、主要影响 | 影响维度 | 具体表现 | |-----------------|--------------------------------------------------------------------------| | **性能** | 99%响应时间(TP99)恶化,吞吐量下降超过50%[^4] | | **可用性** | 网关层触发熔断机制,微服务调用链路中断 | | **资源成本** | 为缓解问题被迫扩容机器,CPU/内存资源浪费 | | **数据一致性** | 长时间GC导致分布式事务超时,引发数据回滚 | --- #### 四、排查与优化建议 1. **基础排查步骤** ```bash # 查看GC统计(JDK9+) jcmd <pid> GC.class_histogram # 生成堆转储文件 jmap -dump:live,format=b,file=heap.hprof <pid> ``` 2. **关键JVM参数调整** ```ini # 老年代与新生代比例 -XX:NewRatio=3 # Survivor区与Eden区比例 -XX:SurvivorRatio=8 # 大对象阈值(单位KB) -XX:PretenureSizeThreshold=1024 ``` 3. **高级优化方向** - 使用G1GC替换ParallelGC:`-XX:+UseG1GC` - 启用元空间监控:`-XX:NativeMemoryTracking=detail` - 限制动态类生成:如配置CGLIB缓存策略 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值