记一次线上OOM异常排查

线上应用OOM告警:GC分析与问题定位

一:背景

        一天线上突然报OOM告警,马上去告警平台去查看JVM监控详情,观察到应用频繁GC,内存一直在高位预警,联想到昨天此应用有新的发布,让运维紧急dump下GC的堆栈信息,立即进行了回滚,回滚后应用运行正常,接下来进行问题的排查;

二:排查

        其实对于这类问题排查起来还是比较简单的,主要的思路是第一时间保护案发现场,将GC日志dump下来,利用可视化工具进行分析,这次我使用JDK自带的工具VisualVM进行GC日志分析,分析如下图

 通过这个图很容易能看到内存溢出的原因是创建了大量的对象(因为我们的系统访问量一般,排除用户的高并发请求,大概率是查询数据的问题),然后跳到概要里查看异常线程,如下图:

通过这个图,可以直接看到发生异常的地方,然后点击进去查看详细情况,如下图: 然后根据TID去日志平台进行搜索,定位到那个功能的异常,然后具体情况具体分析了;

 

### Java 线OOM OutOfMemoryError 解决方案 #### 一、理解 OOM 错误类型 Java 应用程序中的 `OutOfMemoryError` 主要分为几种常见类型: - **Java 堆内存不足(Java Heap Space OOM)** 这种类型的错误表明 JVM 的堆空间不足以完成垃圾回收操作,通常是因为对象过多或单个对象过大。当应用程序创建大量临时对象而未能及时释放时,可能会触发此类错误[^1]。 - **GC Overhead Limit Exceeded** 此错误表示垃圾收集器花费了太多时间尝试清理少量可用内存,导致应用性能严重下降甚至停止响应。Oracle 官方指出该情况通常是由于频繁的小规模垃圾回收造成系统资源耗尽所致[^2]。 #### 二、诊断工具与技术 为了有效定位和解决问题,在线环境下的调试至关重要。可以采用如下手段来捕获必要的信息用于后续分析: - 使用 `-XX:+HeapDumpOnOutOfMemoryError` 参数配置JVM启动参数,使得发生OOM时自动生成heap dump文件供离线分析。 - 利用 VisualVM 或 JProfiler 进行实时监控,观察内存变化趋势以及各代存活对象数量;还可以通过这些工具获取线程转储(Thread Dump),帮助识别是否存在死锁等问题影响正常工作流程。 - 查看日志录,特别是那些由第三方库生成的日志条目,它们可能隐藏着关于异常行为的重要线索。 ```bash jmap -histo:live <pid> | head -n 50 # 显示当前进程中前五十大类实例占用的总字节数量 ``` 上述命令可以帮助快速了解哪些类正在消耗较多的内存资源。 #### 三、具体措施建议 针对不同种类的 OOM 错误采取相应的预防性和修复性行动: 对于 **Java Heap Space OOM**: - 分析 heap dump 文件找出泄露源码位置; - 减少不必要的缓存数据保留期限; - 提高数据库查询效率减少一次性加载的数据集大小; - 合理调整最大堆尺寸(`-Xmx`) 和初始堆尺寸 (`-Xms`) 设置以适应实际负载需求。 面对 **GC Overhead Limit Exceeded** : - 修改 GC算法选项如选用G1收集器替代CMS; - 扩展年轻代比例使更多短生命周期的对象能够在此处被迅速清除而不进入老年代引发全局扫描; - 如果业务逻辑允许的话适当放宽gc开销阈值(-XX:GCTimeRatio=99); - 对于某些特殊场景考虑引入软/弱引用机制代替强引用来管理可选组件间的依赖关系从而降低整体压力. ```xml <property name="spring.datasource.hikari.maximumPoolSize" value="${MAX_POOL_SIZE}" /> <!-- 配置连接池的最大活跃数 --> ``` 合理设置数据库连接池参数也是缓解内存紧张的有效途径之一。 ---
评论 2
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值