内存溢出(Out Of Memory，简称OOM)是指利用零碎中存在无奈回收的内存或应用的内存过多，最终使得程序运行要用到的内存大于能提供的最大内存。此时程序就运行不了，零碎会提醒内存溢出，有时候会主动敞开软件，重启电脑或者软件后开释掉一部分内存又能够失常运行该软件，而由系统配置、数据流、用户代码等起因而导致的内存溢出谬误，即便用户从新执行工作仍然无奈防止。

JVM产生OOM异样可能是以下几种状况：Java堆溢出、虚拟机栈和本地办法栈溢出、办法区和运行时常量池溢出、本机间接内存溢出。这几种状况别离由不同的起因引起。

而在实在的业务场景中，环境往往更加简单。明天，堆堆就带大家学习几个OOM问题排查实战案例，通过几位作者记录的实在案例，揭示本人防止踩坑，也顺便温习相干知识点。
 

1.体验了一把线上CPU100%及利用OOM的排查和解决过程

作者：阿飞云
https://heapdump.cn/article/1...
概述：
作者在收到利用异样告警后，登录了呈现问题的服务器进行查看，在查看服务的日志时发现服务OOM了，紧接着应用Top命令查看零碎中各个过程的资源占用情况，发现有一个过程CPU使用率达到了300%，而后查问该过程下所有线程的CPU应用状况并保留堆栈数据。依据前述操作，获取了呈现问题的服务的GC信息、线程堆栈、堆快照等数据之后，应用HeapDump社区提供的XElephant进行剖析，发现是InMemoryReporterMetrics引起的OOM，进一步发现呈现问题的这个服务依赖的zipkin版本较低，将其降级后解决了问题。

亮点：尽管本文形容和解决的不是常见的疑难杂症，但排查思路清晰，过程残缺，还举荐了排查工具，适宜老手浏览学习。
 

2.一次容器化springboot程序OOM问题探险

作者：侠梦
https://heapdump.cn/article/1...

概述：作者被告知一个容器化的java程序每跑一段时间就会呈现OOM问题，首先查日志并未发现异常；而后通过JStat查看GC状况，发现GC状况失常但ByteBuffer对象占用最高（异样点1）；接着通过JStack查看线程快照状况，发现创立了过多kafka生产者（异样点2）；最初通过编写Demo程序验证猜测，确定问题是业务代码中循环创立Producer对象导致的。

亮点：排查过程清晰明了，工具应用娴熟，验证过程疾速精确。

 

3.一次百万长连贯压测 Nginx OOM 的问题排查剖析

作者：挖坑的张师傅
https://heapdump.cn/article/4...

概述：
作者在一次百万长连贯压测中，发现32C 128G的四台Nginx频繁呈现OOM。发现问题后首先查看了 Nginx 和客户端两端的网络连接状态，首先狐疑是jmeter客户端解决能力无限，有较多音讯沉积在直达的Nginx处，于是dump了nginx的内存查看，动摇了是因为缓存了大量的音讯导致的内存上涨；随后查看了 Nginx 的参数配置，发现proxy_buffers 这个值设置的特地大；而后模仿了upstream 上下游收发速度不统一对Nginx内存占用的影响。最初将proxy_buffering 设置为 off并调小了 proxy_buffer_size 的值当前，Nginx的内存稳固了。

亮点：作者排查思路清晰，工具应用、参数调节非常娴熟，对底层原理和源码了解粗浅，无论是教训还是态度都非常值得学习参考。