JVM成长之路,记录一次内存溢出导致频繁FGC的问题排查及解决

原创 已于 2023-07-20 17:54:52 修改 · 1.6w 阅读 · 49 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#java

于 2017-08-04 21:57:54 首次发布

现象：

现象截图：

内存：

命令： jmap -heap 30069   

GC截图： 

FGC 次数 19529 次！！！何等的恐怖！！！！！

命令： jstat -gcutil 30069 1000

(小记，排查cpu100%，top  看进程cpu， top -Hp  PID 看进程内线程cpu占用， 转成16进制，用jstack查看)

现象描述：

Node模块启动后收到请求却未能响应。 一直在频繁的FGC。新生代内存爆满。老年代内存爆满！

开始分析：

启动Xmx参数为 -Xmx 128M -Xms 128M 
初步判断内存不足，第一次修改： -Xmx 256M -Xms 256M  
=============================================
运行一两天后，Node再次未响应！！！！效果仍然不好 FGC。
=============================================
使用命令查看启动参数：jps -m -l -v
30069 jars/dubhe-node-frame-1.0.0.jar com.dtwave.dipper.dubhe.node.DubheNode --spring.profiles.active=prd -Xms256m -Xmx256m -Xmn64m
 
什么情况？？？
新生代大小大概是 3/8  256 * 3/8 有 120M 可是却被限制到 64M ....
 
 
Xmn只分配了64M。 一旦读日志。新生代满了就直接分配到老年代了！！
于是去掉了这个参数 给Xmn一个自由！！！
=============================================
运行一两天后，Node再次未响应！！！！
=============================================
于是。给xmx翻个倍！
第二次修改：-Xmx 512M -Xms 512M
这样新生代是3/8  170M 了。这样总没问题了吧！！
=============================================

可是。。。。。。。运行一两天后，Node再次未响应！！！！看来之前的解决方法是 错的！！错的！！错的！！

根本不是什么堆空间大小的问题。

=============================================
到底是什么情况！！！！！！！！！！！！！！！！！！！！！！！！！
那就来看看堆里面到底藏了些什么！！！
执行命令：jmap -histo 14273
  1. num #instances #bytes class name
  2. ----------------------------------------------
  3.  1: 1001750 155802576 [B
  4.  2: 137954 32307952 [C
  5.  
最低0.47元/天 解锁文章

200万优质内容无限畅学
JAVA：内存溢出（OOM）问题的排查指南
木头
06-18 717
摘要： Java 内存溢出（OOM）是常见问题，可能因对象无法回收、线程过多、大对象申请等引发。排查时可通过工具链分析： 基础命令：ps/jps定位进程，top监控内存，jstat观察GC情况。 深入分析：jmap导出堆快照或统计对象分布，jstack追踪线程问题，jcmd排查Metaspace泄漏。 解决方案：优化代码（减少强引用、调整缓存）、调整JVM参数（堆大小、GC策略），限制线程或DirectBuffer内存。 综合使用工具定位根源并针对性优化，可有效提升应用稳定性。
FGC问题排查（来自大佬分享）
qq_39809613的博客
07-15 1571
线上服务的GC问题，是Java程序非常典型的一类问题，非常考验工程师排查问题的能力。同时，几乎是面试必考题，但是能真正答好此题的人并不多，要么原理没吃透，要么缺乏实战经验。 过去半年时间里，我们的广告系统出现了多次和GC相关的线上问题，有Full GC过于频繁的，有Young GC耗时过长的，这些问题带来的影响是：GC过程中的程序卡顿，进一步导致服务超时从而影响到广告收入。 这篇文章，我将以一个FGC频繁的线上案例作为引子，详细介绍下GC的排查过程，另外会结合GC的运行原理给出一份实践指南，希望对你有所
面试官：线上环境 FGC 频繁，如何解决？
程序员囧辉
03-19 4751
JVM 大厂面试必问
Java 内存溢出排查优化实战：彻底干掉臭名昭著的 OOM
最新发布
在技术的广袤天地里，本博客如精准罗盘。剖析前沿科技，深掘代码奥秘，以精炼笔触，带您穿越复杂技术迷宫，速达知识彼岸。
05-07 1312
OutOfMemoryError，也就是臭名昭著的 OOM（内存溢出），相信很多球友都遇到过，相对于常见的业务异常，如数组越界、空指针等，OOM 问题 更难难定位和解决。 这篇内容就以之前碰到的一次线上内存溢出的定位、解决问题的方式展开；希望能对碰到类似问题的球友带来思路和帮助。 主要从表现-->排查-->定位-->解决 四个步骤来分析和解决问题。
大量数据更新导致fgc频繁引起jvm服务暂停。
诗剑书生的专栏
07-11 6293
线上跑的几台服务器突然出现大量fgc，由于在fgc过程的stop the world太久，引起其它应用访问该服务器上的接口大量超时。（发生超时的时间点和fgc时间点一致）先进行初步的优化。方案：修改CMSInitiatingOccupancyFraction=85这个调低到60，加快cms gc处理防止concurrent mode failure触发FGC,           减少CMSMax
频繁FGC的真凶原来是它
热门推荐
dam454450872的博客
05-13 1万+
上周排查了一个线上问题，主要现象是CPU占用过高，jvm old区占用过高，同时频繁fgc，我简单排查了下就草草收场了，但是过后我对这个问题又进行了复查，发现问题没有那么简单，下面跟着我一起分析一下到底是怎么回事？ 一定要先读完上篇文章 cpu占用过高和jvm old占用过高排查过程 复查过程 复查原因 事后再看dump文件注意到最大的对象是一个ArrayList，里面几乎都是...
FGC频繁
06-01 679
1、假如FGC次数增加，达到一小时一次，但是gc之后，内存也立马降下来了； 这说明并没有发生内存泄露；只是新生代的对象过早的进入的老年代； 解决办法有 增加年轻代空间，以减少youngGc，这样就不会有对象过早的进入老年代 增加年轻代进入老年代的年代阀值，可以增加到最大的15次 ...
性能测试常见的内存溢出问题： JVM 内存溢出如何调优？
qq_43371695的博客
07-10 1116
针对java项目做性能测试的时候，很多同学都见过一个报错，就是OOM【Out Of MemoryError】；那出现这种报错就是项目发生了内存溢出的问题，这是比较严重的性能问题。所以，作为一个性能测试工程师，我们要能够分析JVM内存的问题以及理解其中的原理，才能更好的给JVM内存出现的性能瓶颈问题进行调优。
记录一次大对象导致的Java堆内存溢出问题
Lnho的专栏
08-29 7234
前几天早上出现一后台项目无法登陆的情况，排查发现新生代和老年代都占用100%，FullGC次数大概有100多次，最终出现OOM。 重启Tomcat后，至13点，FullGC的次数达到31次。
JVM内存溢出原理及案例分析
weixin_43865008的博客
07-30 1846
前言 再程序中，什么是内存溢出呢？什么情况下会出现内存溢出呢？ 内存溢出原理 一般来说，程序中出现内存溢出是非常严重的，一但出现内存溢出，会导致程序无法正常运行。一般再程序中，内存溢出分为两种：一种是 堆内存溢出。，一种是永久代溢出。 堆内存溢出： 堆内存中存在大量的对象，这些对象都被引用，当所有对象占用空间达到堆内存的最大值，就会出现内存溢出 OutOfMemory：java heap space 其实当内存满的时候，程序会触发GC，但是GC之后发现内存都被占用无法进行回收,导致无法腾出空间，内存空
性能测试中你是否遇见过频繁fgc的问题呢？
李文良的博客
07-07 1万+
前言：今天分享一个频繁fgc的问题，现象是接口响应时间太长了，达到了好几秒，远远高于预期的1秒。 xshell连接到应用服务器，服务器负载高，且cpu使用率也偏高。 使用jstat看了下gc的情况，fgc很频繁，老年代满了（下图的O列） 打开JvisualVM，双击对应的应用进程，然后进入Monitor，可以看到堆内存GC频繁。然后进入 Visual GC查看，发现堆内存Full GC非常频繁. 根据下面gc日志，Full GC Old区回收的内存很少。 现在情况就非常明显了，就是内存中有大量GC不
Java线上程序频繁JVM FGC问题排障与启示
无界编程
10-16 3830
线上Java程序的JVM频繁FGC，现象如图所示： 一直持续FGC 5次左右，每次耗时1秒多不等。 FGC的原因实际上是内存不够用，但是运维反映堆内存是2G，从运维提供的参数看也是。 内存实际上一直只用到1G以内。 这时候可以自己写一段代码输出堆内存数据，这是最准的： public class JVMTest { public static void main(Str...
JVM一直FullGC内存溢出定位
guaotianxia的博客
11-09 3904
JVM内存溢出是java编码比较常见的一种性能问题，这种问题在开发和测试环境不容易发现，但是上线初期项目运行一段时间，很容易出现。比较常见于excel导出，非分页大数据量查询等，在工作期间也多次遇到和处理此类问题，分享下定位方法。 内存溢出现象：界面访问突然卡顿，刷新后无法加载出页面。用F12查看，一直处于后端请求直到超时报错；后端查询日志，基本无日志输出，仅仅从日志层面无法看出什么原因导致。 内存溢出原因：大量创建对象，对象处于存活状态，对象在老年代中fullGc无法回收，一直fullgc导致st..
频繁FGC的坑
pliulijia的专栏
01-20 877
问题重现 2020年新年伊始，排查一个线上GC问题。最直观的现象就是，1月2号线上一个Elasticsearch查询服务突然报警，几乎同时业务反馈某实时报表数据查询页面报错。同时看到后台日志java.lang.OutOfMemoryError: GCoverheadlimitexceeded,Eurake注册服务页面也已经没有检测到心跳，主动把此服务从注册中心列表服务剔除。情况紧急，此服务集群节...
系统GC问题排查方法总结
Darlight的博客
07-17 7071
一文教你如何解决系统out of memory问题
FGC问题排查
04stone37
04-09 4191
问题及原因分类 FGC问题分类 目前遇到的FGC问题主要分为两大类： FGC频繁（频率高）； 停顿时间长（FGC持续时间长）； FGC原因分类 引发FGC问题的原因也主要分为两大类： JVM参数设置不合理； 程序Bug； FGC频繁排查 JVM参数不合理 Young与Old比例不合理 Old空间占比过小； Eden与Survivor比例不合...
应用启动FGC频繁问题排查
04stone37
01-31 1284
现象   应用刚启动的几分钟内固定的发生3次FGC，之后平稳不再GC； GC日志分析   从GC日志可以看出，Metaspace容量达到上限分别触发了一次YGC和FGC，而且Metaspace容量的容量在变大这说明Metaspace容量在不断扩容，这说明Metaspace容量设置过小导致应用启动时发生了扩容，查看JVM参数发现没有显式指定Metaspace容量，默认为20M； GCeasy可视化...
JVM FGC
wokaotesting
07-26 4215
JVM FGC +CMSParallelRemarkEnabled
内存飙高问题如何排查？
cj_eryue的博客
02-29 3031
内存飙高如果发生在java进程上，一般情况是因为创建了大量对象导致，持续飙高说明垃圾回收跟不上对象创建的速度，或者内存泄漏导致对象无法被回收！排查中涉及到如下命令：jstat -gc pid 1000 查看gc情况，时间等信息，每隔一秒打印一次jmap -histo pid | head -20 查看堆内存占用空间最大的钱20个对象类型jmap -dump:live,format=b,file=/home/chenjian/myheapdump.hprof pid 导出堆内存快照。
堆内存溢出怎么排查
03-24
<think>好的，我现在需要帮助用户了解如何排查Java堆内存溢出问题。用户已经提供了一些参考引用，我需要结合这些资料，整理出一个清晰的步骤指南。首先，我需要回忆常见的堆内存溢出原因，比如内存泄漏、大对象分配、不合理的JVM配置等。然后，根据用户提供的引用内容，看看他们提到的排查方法有哪些。 引用[1]中提到了模拟内存溢出场景，通过循环创建大对象导致内存溢出，这可能用于复现问题。引用[2]和[4]提到了使用jstat、jconsole、jvisualvm等工具监控内存使用情况，特别是老年代和GC情况。引用[3]则涉及分析线程堆栈，查看哪个线程导致了问题，并考虑Full GC无法回收的情况。需要将这些步骤有条理地组织起来。 首先，用户需要确认错误类型，是否是OutOfMemoryError: Java heap space。然后，使用内存分析工具获取堆转储文件，比如-XX:+HeapDumpOnOutOfMemoryError参数。接着，通过jstat监控GC情况，如果Full GC频繁且回收效果差，可能存在内存泄漏。分析堆转储文件，查找占内存最多的对象和其引用链，确定是否有无法释放的对象。同时，检查代码是否有内存泄漏，比如未关闭的资源、集合类缓存未清理等。 需要注意引用[3]中的例子，即使线程本身不创建大量对象，可能是之前的内存泄漏积累导致。因此，需要综合多种信息，不能仅看错误提示的线程。另外，用户可能需要调整JVM参数，比如增大堆大小，但如果是内存泄漏，这只能延缓问题，不能根本解决。 最后，生成相关问题，比如工具使用、内存泄漏定位、参数调整等，帮助用户进一步学习。确保回答结构清晰，分步骤说明，并正确引用提供的资料。</think>Java堆内存溢出排查可分为六个关键步骤，结合工具监控和代码分析进行定位： 一、确认错误类型 检查错误日志中是否明确出现$OutOfMemoryError: Java heap space$，这是堆内存溢出的典型特征[^1][^3] 二、配置堆转储 启动参数添加： ```java -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump ``` 当OOM发生时自动生成hprof文件[^4] 三、实时监控 1. 使用jstat监控GC状态： ```bash jstat -gcutil <pid> 1000 20 # 每秒采样持续20次 ``` 观察$FGC$（Full GC次数）和$FGCT$（Full GC耗时）是否持续增长，$O$（老年代使用率）是否持续高位[^2] 2. 通过jvisualvm连接进程，查看： - 堆内存曲线变化 - 对象创建直方图 - 存活对象树状图 四、分析堆转储 使用MAT或jhat分析hprof文件： 1. 查找占用最大的对象 2. 检查支配树中的异常对象链 3. 对比多次dump文件观察对象增长趋势 五、代码审查重点 1. 静态集合缓存（如HashMap）是否未清理 2. 流资源未关闭（数据库连接、文件句柄） 3. 第三方库的内存使用模式 4. 线程局部变量积累 六、场景验证 参考创建最小复现案例： ```java // 模拟内存泄漏 List<byte[]> leakList = new ArrayList<>(); while(true) { leakList.add(new byte[1024*1024]); } ```
评论 5
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值