共计 1413 个字符，预计需要花费 4 分钟才能阅读完成。
内存溢出 (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 的内存稳固了。
亮点：作者排查思路清晰，工具应用、参数调节非常娴熟，对底层原理和源码了解粗浅，无论是教训还是态度都非常值得学习参考。
