【Java】2023年业务实践中遇到的所有OOM情况及实战总结

发布时间:2024年01月08日

引言:

在Java开发中,随着应用程序变得越来越复杂,内存管理问题也变得愈加重要。而在JVM中的"OOM"(Out of Memory)错误是Java程序员经常面临的一种挑战。本文将深入探讨JVM OOM错误,了解其原因、种类以及如何处理,在文中的最后,也总结了常用的JVM内存分析工具。

一、JVM内存结构

知其然,知其所以然。为了更好地理解JVM OOM错误,首先可以先了解JVM的内存结构。JVM将内存划分为以下几个区域:

  1. 堆内存(Heap): 堆内存是用于存储对象实例的主要区域。在堆中,包括新生代(Young Generation)、老年代(Old Generation)和永久代(或元数据区,Metaspace)等子区域。

这里的新生代、老年代…只针对部分虚拟机而言,众所周知,虚拟机发展至今,也有不采用分代设计思想的虚拟机。

  1. 方法区(Method Area): 方法区用于存储类的信息、常量池、静态变量等。在Java 8及之后的版本中,方法区被取代为Metaspace。
  2. 虚拟机栈(Stack): 栈内存用于存储方法调用的局部变量、操作数栈、方法出口等信息。
  3. 本地方法栈(Native Method Stack): 用于执行本地方法(Native Method)的栈。

在Java虚拟机规范中,对这一部分的实现并没有规定,像Hot-Spot虚拟机会把它和虚拟机栈合二为一。

  1. 程序计数器(Program Counter Register): 记录正在执行的字节码指令地址。

在这里插入图片描述

值得一提的是在上述区域中,程序计数器是唯一一个在Java虚拟机规范中没有规定任何OOM情况的区域。那么其他区域会在什么情况出现OOM呢?

二、JVM OOM错误情况

除去程序计数器,其他区域根据Java虚拟机规范,在无法满足新的内存分配需求时,将抛出OOM异常。根据区域的不同,大致可以划分为如下几种情况:

  1. 堆内存溢出(Heap Space OOM): 当堆内存无法满足新对象的分配请求时,会发生堆内存溢出错误。这通常是由于创建了太多的对象或某些对象过大,而堆内存不足以容纳它们引起的。
  2. 方法区溢出(Metaspace OOM): 在Java 8及之后的版本中,方法区被取代为Metaspace,如果加载的类或元数据信息过多,会导致Metaspace溢出错误。
  3. 栈内存溢出: 这个区域在递归调用的深度过深,导致栈帧无法被正常释放时,会抛出Stack OverflowError,如果虚拟机栈支持动态扩展,则扩展失败时会抛出OOM
  4. 本地方法栈溢出(Native Method Stack Overflow): 类似于栈内存溢出,但是发生在本地方法调用时。

上述区域为虚拟机运行时数据区的一部分,而在这之外,还有一个叫做直接内存的区域,该区域也不是Java虚拟机规范中定义的区域。我们知道,在JDK1.4 中,NIO类引入了基于Channel与Buffer的I/O方式,通过Native函数库直接分配堆外内存。而对这部分的内存使用,如果不加以管理,同样存在OOM情况。

尽管我们知道了可能发生OOM的区域,但在OOM发生时还是容易头大,这一方面可能是由于日志链路不足以支撑分析,一方面也可能是经验不足,排查思路不够清晰。下面以业务上的几次OOM实践经历作为分析,会讲述在日志情况不足以定位到OOM时,做了哪些尝试,同时梳理了排查定位思路,希望能帮上一二。

三、实践

案例一

某次午休时间,突然告警,原因是OOM导致容器重启了。由于重启后,日志文件随之情况(该服务平常无日志采集),无开启OOM dump现场配置,可以说是两眼一黑。
在这里插入图片描述

该情况无从下手,那么我们优先开启如下配置,在OOM时进行dump,并保存至/app目录,观察分析一段时间。

java -XX:HeapDumpPath=/app/dumpfile.hprof -jar YourApplication.jar

一天过去后,仍然无果,无OOM、无告警。那么此时暂且排除某个大对象直接导致OOM可能,怀疑是否存在内存泄漏,即应用程序中存在着回收不掉的对象,一直在堆积,且有较大概率非用户操作引起的(因为之前在一天的用户操作过程中也没再发生)。那么开启第二个参数(NMT),用于Java虚拟机(JVM)本机内存跟踪,这个参数会让程序有一定的性能损耗,线上服务需要进行足够的评估。这里在预发机器上添加了该配置:

- -XX:NativeMemoryTracking

启动机器,打印内存情况,打印参数如下:

jcmd pid VM.native_memory summary

内存情况如下:

在这里插入图片描述

同样在运行一天后,再打印内存情况:
在这里插入图片描述

这里可以看到Thread占用的内存上涨得很快,其中 reserved 为1084M,committed 为1084M,每个栈大小为1M。那么我们可以dump一下线程的情况,这里直接用了arthas 中的thread命令,去查看线程的基本信息:

在这里插入图片描述

可以观察到存在着大量的myScheduler线程,其中不少处于waiting 状态。这时我们可以在业务代码里搜索myScheduler 相关的配置,可以发现该线程池大小为1000,再了解相关的业务是否真的需要这么多的线程执行,那么找到了解决方式:

  • 优化线程池配置,调整核心线程数,调整线程池大小
  • 根据业务实际情况,调整-Xmx 对应内存大小

案例二

某次傍晚晚时间,线上一核心服务重启告警。此时第一反应为什么重启了呢?观察容器错误日志,可以发现导火索是容器健康检测失败后,重启了容器。

健康检测:定期地检测容器内的应用程序或服务,并在出现问题时采取适当的措施(如:重启)

为什么健康检测会失败?因为线上服务开启了 -XX:+PrintGCDetails 参数,我们可以比较方便的拿到了gc-log文件。

-XX:+PrintGCDetails -XX:+PrintGCDateStamps -Xloggc:/path/gc-log.log

  • -XX:+PrintGCDetails:打印详细的 GC 信息。
  • -XX:+PrintGCDateStamps:在 GC 日志中包括日期时间戳。
  • -Xloggc:/path/gc-log.log:指定 GC 日志的输出文件路径。

在这里插入图片描述

拿到gc-log文件,我们可以借助 gceasy.io网站分析,该网站提供了直观的图形化界面,帮助开发者轻松地监测和分析垃圾回收事件。如图:我们可以很直观的看到在20:40-21:30的时间段内heap飙升,且GC 之后,几乎没有效果。观察STW 时间最长的可以去到2min,同时CPU几乎拉满了,那么这里我们怀疑是否存在内存泄漏

这次,因为启动参数配置了参数: -XX:HeapDumpPath,且在对应路径下,找到了现场dump文件,那么我们可以借助MAT(Eclipse Memory Analyzer)工具分析。在加载完dump文件,可以看到MAT分析的结果似乎也没有什么明显的异常提示, 那么我们可以尝试从占用空间比较大的的对象入手,从根节点开始分析,在MAT中,使用"Path to GC Roots"功能,即可从根对象开始查找对象引用链:

在这里插入图片描述
在这里插入图片描述
到这里我们发现占用的大量对象由TimerEndInterceptor类持有,每次GC回收都没有将其中对象回收掉。而这个 TimerEndInterceptor 类是基础服务团队维护的 metrics-agent 组件产生的。后续也是联系了他们回滚了metrics-agent 版本解决了问题。

简单而言就是,TimerEndInterceptor 类中的 ConcurrentHashMap(timeMap) 内存占用过高导致应用频繁FULL GC,打满了cpu导致dubbo服务不可用

案例三

在前两个案例归根到底是内存泄漏导致的OOM,这个过程的对象占用空间是缓慢增加的。那么在这个案例将以某次程序调用产生的大对象直接导致容器OOM为例子进行分析。同事A说某个线上服务运行一段时间就会挂了。对于这种必现的问题还是比较好下手的,我们同样加 -XX:HeapDumpPath 参数重启服务,在服务又挂了之后,我们在对应的路径下找到了dump文件,同样借助MAT工具分析。
在这里插入图片描述
在这里插入图片描述

这次事故定位速度就很快了,因为MAT工具对于一些可疑大对象会有直接的提示,我们可以根据提示查找堆栈信息。在上图,通过堆栈链路我们定位到了代码位置。其实就是某个请求一次性从数据库捞出了很多数据,由于数据过大,直接分配在了老年代,而young gc 是不会回收这部分空间了,导致老年代不断膨胀,引发频繁的full gc,最终在内存超过限制后,触发OOM。那么争对这个问题我们可以有如下解决方式:

临时解决方案:

  • 先调高JVM内存
  • 配置 -XX:PretenureSizeThreshold 参数,适当调大对应的值,让大对象不要进入老年代在年轻代分配

年轻代的对象生命周期相比于老年代较短,如果能随着yong gc及时处理了这些对象,也可以及时释放掉这些空间

长久解决方案:

  • 代码优化

四、总结

在此次OOM分析和实战中,我们先了解了JVM内存结构,知道了OOM会存在于JVM的哪些区域,接着阐述了根据区域的不同,OOM大概有哪几种类及其产生的原因,最后我们我们以三个案例进行实践和分析。这里我们再把排查思路汇集一下:

  • 程序OOM时,保留现场dump文件很重要的分析依据。那么根据服务重要性,我们平常可以在服务启动时配置 -XX:HeapDumpPath 参数。
  • 如果程序重启时, -XX:HeapDumpPath 对应路径下无对应日志文件:
    • 确认对应路径是容器路径还是挂载的磁盘路径,如果是前者,会随容器重启而消失
    • 如果你的业务里也有类似健康检测机制,考虑是否存在检测超时间小于dump完成时间,导致还没来得及dump完成就重启了容器

    第二种情况,还可以确认一下 -Xmx 对应内存大小,内存越大,dump时间越久

  • 如果有开启 -XX:+PrintGCDetails 参数,我们还可以借助easygc 等网站,分析JVM 的GC情况。看看是否存在频繁full gc,full gc耗时是否过长。
  • 针对dump文件的分析,我们可以借助MAT(Eclipse Memory Analyzer)工具。如果是大对象直接导致的OOM,我们一般可以在概览图(overview)里找到对应提示;如果是内存泄漏导致的OOM,MAT此时可能无明显提示,那么我们可以从占比较高的对象入手,从root 节点开始找引用链,从而最终定位到疑似对象。
  • 除去以上方式,对于内存泄漏导致的OOM,如果线上服务实在缺乏充分条件分析,我们也可以在测试环境开启NMT(-XX:NativeMemoryTracking) 参数进行前后的对比分析。

五、分析工具推荐

在上述分析中,我们用到了 GC Easy和MAT工具,但除此之外,还有一些类似的网站和工具,可以帮助你分析和优化Java应用程序的性能和内存管理。以下是一些常用的网站和工具:

  1. FastThread.io https://fastthread.io/ FastThread.io 是一个在线工具,用于分析Java线程转储文件(Thread Dump)和堆转储文件(Heap Dump),以帮助你识别性能问题和线程问题。
  2. jHiccup: https://github.com/jHiccup/jHiccup jHiccup 是一个工具,用于测量JVM的停顿时间(暂停时间)和延迟,有助于检测应用程序的性能问题。
  3. jProfiler: https://www.ej-technologies.com/products/jprofiler/overview.html jProfiler 是一款商业性能分析工具,提供了强大的性能分析和调试功能,包括堆分析、线程分析、方法追踪等。
  4. New Relic: https://newrelic.com/ New Relic 是一种全栈性能监控工具,可用于监控和分析应用程序的性能、事务、错误和分布式追踪等。
  5. AppDynamics: https://www.appdynamics.com/ AppDynamics 提供了应用性能监控和实时分析工具,可帮助你监视Java应用程序的性能指标和事务。
  6. Dynatrace: https://www.dynatrace.com/ Dynatrace 是一种全栈性能监控工具,提供了自动化的性能分析和故障检测功能,适用于各种应用程序类型。

这些工具和网站各有特点,可以根据实际情况选择合适的工具来分析和优化你的Java应用程序的性能和内存管理。

六、参考文献

[1]Ali Dehghani. Native Memory Tracking in JVM[EB/OL].

[2]hengyunabc, Fatpandac, Hearen, Hollow Man, gongdewei, 李鼎. arthas thread[EB/OL].

[3]周志明. 深入理解Java虚拟机.

文章来源:https://blog.csdn.net/legendaryhaha/article/details/135457257
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。