如何快速定位OutOfMemoryError发生的地方和原因

问题

相信你做的项目在日常运行中肯定遇到过OOM,内存不足。什么?你没遇到过!那你也得看看,先了解下,以后肯定会遇到的,相信我!

PS. 以下可能会出现一些专业名称,你了解的话还好,不了解的话我也不过多解释,自己百度吧,只说怎么找问题。

image-20200619112703492

我遇到的场景:

  1. 慢SQL:在业务处理中前一步查到的数据交给下一步处理,而下一步又查询的很慢。导致大量线程堆积在内存中等待执行,然后大量的数据等待下一步处理无法释放,最终结果就内存溢出了。

  2. 阿里OSSClient没有关闭:项目中用到了阿里oss存储照片,每次上传完图片图片后没有及时shutdown,OSSClient连接存在内存中未关,占用大量内存。

常见解决方案

  1. 重启项目

  2. 增大项目启动的内存设置

    《阿里巴巴开发手册》的建议:我收集的学习资料

    image-20200619150051352

但这些都是治标不治本,项目运行久了还是会出现的;

本着大多数问题都是因为代码没写好引起的理念,所以问题应该从代码着手。但具体是哪个方法、哪一行代码如果日志里分析不出来的话,那么我这篇博客就派上用场了。

诊断流程

  1. 项目运行中发生OOM时,需要导出dump文件用来分析问题,有两种方式:

    1. 执行此命令:jmap -dump:format=b,file=oom.dump pid ,会生成当前pid进程对应的内存镜像文件oom.dump

    2. 或者在启动命令里配置启动参数,下次出现OOM时会自动生成oom.dump

      -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/log/oom.dump

      image-20200810155050931

  2. Windows环境 - 对已导出的dump文件进行分析

    说明:可使用jdk自带的jvisualvm.exe进行分析,jvisualvm.exe在你自己装的jdk/bin/jvisualvm.exe目录下

    1. 打开jvisualvm.exe,选择文件-装入,选择文件类型堆 Dump(*.hprof,**),就可以装入你的文件了

    2. 装入后可以看到好多信息

      image-20200619120831992

      image-20200619121046019

      image-20200619121310897

由上面可以看出数组占用最大,初步怀疑可能是它占用内存没有即时释放

image-20200619121715496

果然是一直往list中存放数组,不能释放,结果就OOM了。这是我设置的启动参数-Xms128m -Xmx256m,所以就可以 试出来。

  1. Linux环境 - 对已导出的dump文件进行分析

    说明:使用Mat工具;因为导出的dump文件往往都是好几G,最好的话就在Linux上进行分析了

    1. 下载链接https://www.eclipse.org/mat/downloads.php,选择合适的包就可以,并解压到Linux里

    2. MAT分析 dump,该命令会执行一段时间

      ./ParseHeapDump.sh oom.dump  org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components
      ​
      #使用该命令如果报MAT内存不足的异常:
      #修改MemoryAnalyzer.ini 的 -Xmx,默认是1024m,大小比dump文件大就可以。

       

    3. 结果会生成一些文件,找到这三个后缀的压缩文件,比较小,可下载到本地解压用浏览器查看index.html

      image-20200619141708455

      image-20200619142044838

      image-20200619142314134

发生

看下源码,java.lang.OutOfMemoryError类为什么会抛出这个错误

image-20200619145348337

如何避免发生OOM,网上资料很多,我就不赘述了。

步骤总结

1. #下载Mat工具,并解压
https://www.eclipse.org/mat/downloads.php
​
2. #导出当时内存镜像
jmap -dump:format=b,file=oom.dump pid
​
3. #使用MAT文件中ParseHeapDump.sh脚本分析 dump,该命令测试环境会执行30秒左右,正式环境估计会执行1-2分钟
./ParseHeapDump.sh oom.dump  org.eclipse.mat.api:suspects org.eclipse.mat.api:overview org.eclipse.mat.api:top_components
​
4. #下载生成的三个压缩包就可以分析了

 

### JVM 内存模型 Java 虚拟机(JVM)内存被划分为多个不同的区域,这些区域各自承担特定的任务并具有独特的特性。 #### 方法区 方法区存储已被虚拟机加载的类信息、常量、静态变量、即时编译后的代码等数据。此部分可以设置参数`-XX:+HeapDumpOnOutOfMemoryError`使得在发生 `OutOfMemoryError` 错误时生成堆转储文件以便分析[^2]。 #### 堆 堆是所有线程共享的一块最大的内存区域,在几乎所有的应用中都是垃圾收集器管理的主要对象。它又细分为新生代老年代两个子域: - **新生代 (Young Generation)**:大多数情况下新创建的对象都会优先分配在此处。由于这部分经常有大量短生命周期的对象产生,因此频繁执行年轻代回收即Minor GC/Young GC。 - **老年代 (Old Generation)**:经过多次存活下来的对象会被晋升到老年代。这里发生的Full GC涉及整个堆空间,包括永久代或元空间,通常频率较低但耗时较长。 #### Java栈 每个线程都有独立的一个Java栈,它是用来保存局部变量表、操作数栈、动态链接、返回地址等信息的地方。每当启动一条新的线程就会为其创建相应的Java栈实例。 #### 本地方法栈 与Java栈作用相似,不过这里是专门为Native Method服务的空间。 #### PC寄存器 程序计数器是一块较小的内存空间,它的唯一目的是记录当前线程所执行字节码指令的位置。 #### 直接内存 虽然不属于传统意义上的JVM运行时数据区组成部分之一,但在某些场景下也会涉及到直接内存的操作。这类内存在使用前需借助于JNI接口向操作系统请求获取,并且不受限于常规意义上由GC负责清理范围之内;如果超出可用限度则可能触发`OutOfMemoryError`异常[^3]。 ### 垃圾回收算法 为了提高效率,针对不同类型的内存分区采用了多种策略相结合的方式来进行垃圾回收工作: #### 新生代回收 对于新生代而言,主要采取的是复制算法。考虑到大部分对象很快便会成为垃圾的特点,只需少量移动存活下来的数据即可完成清理过程。然而这种方式也意味着每次都需要预留足够的备用空间供转移之用。 #### 老年代回收 相比之下,老年代中的对象往往拥有更长的生命期,故而更适合运用标记清除或是标记整理的方法处理。前者能够快速定位待释放的部分,后者除了标注外还会将剩余的有效元素紧凑排列在一起从而减少碎片化现象的发生。 #### 分代回收机制 实际上所谓的分代回收正是基于上述两种思路之上发展起来的一种综合性解决方案——即将整个堆分成若干个小单元分别对待,依据各自的特征选取最合适的清扫手段组合而成。例如,当Eden区或者Survivor区不足以容纳新增加的内容时,则会触发一次轻度的小规模搜集活动(Minor GC),反之若是老年区内出现了容量不足的情况,则不得不进行全面的大扫除(Full GC)[^5]。 ```java // 示例代码展示如何强制建议进行垃圾回收(尽管实际效果取决于JVM实现) public class GCDemo { public static void main(String[] args) { System.gc(); // 提交垃圾回收请求给JVM, 不保证立即执行 } } ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值