Out of memory (OOM) 是一种操作系统或者程序曾经无奈再申请到内存的状态。常常是因为所有可用的内存，包含磁盘替换空间都曾经被调配了。OOM 的官网解释是：Understand the OutOfMemoryError Exception，依据 HeapDump 性能社区专属讲师公与的总结，常见的 OOM 有以下 10 种（其中 OOM Killer 是操作系统层面的概念）。
那些年咱们遇到的 OOM- 开题
开篇举荐的是公与大佬的视频课程《那些年咱们遇到的 OOM》第一期，在本期课程中，公与从新梳理了公众对于 OOM 的了解和认知，简略而清晰地介绍了 Java 虚拟机内存散布，并对本系列课程中呈现的 10 种 OOM 进行了简略的解读，观看此视频课程能让大家对 OOM 有一个整体的意识。
不同类型的 OOM 产生起因是什么？生产环境碰到 OOM 该如何剖析、怎么解决？有哪些好的定位工具？
本期 HeapDump 性能社区 OOM 专题文章就收录了 20 篇相干文章，蕴含专家经验总结、大佬源码剖析，以及大量的实战案例。心愿大家读完都有播种。
第一局部：实践篇
1.JVM 产生 OOM 的 8 种起因、及解决办法
作者：占小狼
本文简略介绍了 8 种 OOM 的产生起因及其解决办法，包含分析方法、排查命令、参数调优思路等。
2. 一篇说明确什么是 oom，为什么会 oom，oom 的类型和常见解决办法
作者：G.Shine
本篇最早来自博客园 G.Shine 2012 年的一篇文章，是对于 OOM 问题总结得最简略，也最易懂的一篇。
波及到的虚拟机的技术或者工具，往往须要思考到虚拟机标准以及不同的虚拟机实现。尤其是针对虚拟机调优时，往往须要针对虚拟机在某些方面的实现策略来思考，比方，不同的虚拟机的垃圾回收算法是不一样的，而这间接影响了虚拟机某些参数的设置，以达到虚拟机的最佳性能。而针对 JVM 运行时的剖析与诊断，则须要把握剖析根本办法，针对具体情况，使用虚拟机的原理，具体分析，能够多看看 HeapDump 性能社区里 JVM 相干的文章，也能够应用社区的 XXFOX 工具：https://opts.console.heapdump.cn/
3.JVM 源码剖析之临门一脚的 OutOfMemoryError 齐全解读
作者：你假笨
OutOfMemoryError，说的是 java.lang.OutOfMemoryError，是 JDK 里自带的异样，顾名思义，说的就是内存溢出，当咱们的零碎内存严重不足的时候就会抛出这个异样 (PS: 留神这是一个 Error，不是一个 Exception，所以当咱们要 catch 异样的时候要留神哦)，这个异样说常见也常见，说不常见其实也见得不多，不过作为 Java 程序员至多应该都听过吧，如果你对 jvm 不是很熟，或者对 OutOfMemoryError 这个异样理解不是很深的话，这篇文章必定还是能够给你带来一些惊喜的，通过这篇文章你至多能够理解到如下几点：
- OutOfMemoryError 肯定会被加载吗
- 什么时候抛出 OutOfMemoryError
- 会创立有数 OutOfMemoryError 实例吗
- 为什么大部分 OutOfMemoryError 异样是无堆栈的
- 咱们如何去剖析这样的异样
4.Java 中利用软援用和弱援用来防止 oom
作者：Matrix 海 子
本文先介绍了无关强援用、软援用、弱援用、虚援用的相干概念，而后举例解说如何利用软援用和弱援用来防止 OOM：如果有一个利用须要读取大量的本地图片，如果每次读取图片都从硬盘读取，则会重大影响性能，然而如果全副加载到内存当中，又有可能造成内存溢出，此时应用软援用能够解决这个问题。设计思路是：用一个 HashMap 来保留图片的门路和相应图片对象关联的软援用之间的映射关系，在内存不足时，JVM 会主动回收这些缓存图片对象所占用的空间，从而无效地防止了 OOM 的问题。在 Android 开发中对于大量图片下载会常常用到。
5.OOM 系列之八：java.lang.OutOfMemoryError: Kill process or sacrifice child
此文来自于 plumbr 官网，plumbr 是一个罕用的 JVM 监测工具，官网有残缺的 oom 和 gc 文章，自己仅作翻译转载，此篇为完结篇。
第二局部：实战篇
6. 体验了一把线上 CPU100% 及利用 OOM 的排查和解决过程
作者：阿飞云
作者在收到利用异样告警后，登录了呈现问题的服务器进行查看，在查看服务的日志时发现服务 OOM 了，紧接着应用 Top 命令查看零碎中各个过程的资源占用情况，发现有一个过程 CPU 使用率达到了 300%，而后查问该过程下所有线程的 CPU 应用状况并保留堆栈数据。依据前述操作，获取了呈现问题的服务的 GC 信息、线程堆栈、堆快照等数据之后，应用 HeapDump 社区提供的 XElephant 进行剖析，发现是 InMemoryReporterMetrics 引起的 OOM，进一步发现呈现问题的这个服务依赖的 zipkin 版本较低，将其降级后解决了问题。本文形容和解决的尽管不是常见的疑难杂症，但排查思路清晰，过程残缺，还举荐了排查工具，适宜老手浏览学习。
7. 一次容器化 springboot 程序 OOM 问题探险
作者：侠梦
作者被告知一个容器化的 java 程序每跑一段时间就会呈现 OOM 问题，首先查日志并未发现异常；而后通过 JStat 查看 GC 状况，发现 GC 状况失常但 ByteBuffer 对象占用最高（异样点 1）；接着通过 JStack 查看线程快照状况，发现创立了过多 kafka 生产者（异样点 2）；最初通过编写 Demo 程序验证猜测，确定问题是业务代码中循环创立 Producer 对象导致的。排查过程清晰明了，工具应用娴熟，验证过程疾速精确。
8. 一次实在的线上 OOM 问题定位
作者：王政
笔者负责的一零碎生产环境上呈现了 OutOfMemoryError，随同着这个问题随之而来的是一堆 Full GC，CPU 百分之百，频繁宕机重启等问题，重大影响业务的推广及应用，此类问题个别解决起来比拟辣手，本文将此问题的呈现及定位解决过程做下梳理，以便对后续解决相似问题提供参考领导。
9. 一次百万长连贯压测 Nginx OOM 的问题排查剖析
作者：挖坑的张师傅
作者在一次百万长连贯压测中，发现 32C 128G 的四台 Nginx 频繁呈现 OOM。发现问题后首先查看了 Nginx 和客户端两端的网络连接状态，首先狐疑是 jmeter 客户端解决能力无限，有较多音讯沉积在直达的 Nginx 处，于是 dump 了 nginx 的内存查看，动摇了是因为缓存了大量的音讯导致的内存上涨；随后查看了 Nginx 的参数配置，发现 proxy\_buffers 这个值设置的特地大；而后模仿了 upstream 上下游收发速度不统一对 Nginx 内存占用的影响。最初将 proxy\_buffering 设置为 off 并调小了 proxy\_buffer\_size 的值当前，Nginx 的内存稳固了。作者排查思路清晰，工具应用、参数调节非常娴熟，对底层原理和源码了解粗浅，无论是教训还是态度都非常值得学习参考。
10. 一则 OOM 死机故障的处理过程
作者：兔兔七
笔者这次遇到的故障属于典型的内存不足，导致产生 OOM 谬误的状况。从零碎状态和日常的监控以及系统日志的报错等都可发现形迹，但缺没有引起足够的器重，最终导致死机。另外，mrtg 运行出错，而发送大量垃圾邮件，引起 amavisd 调用 clamscan 被卡的问题也使零碎不堪负载。相似的问题，须要针对零碎进行监控以剖析起因能力采取有效的措施。同时，管理员也不能漠视日常的保护工作，免得呈现无可解救的故障。
11. 为什么容器内存占用居高不下，频频 OOM
作者：煎鱼
作者的我的项目在上 Kubernetes 的前半年，只是用 Kubernetes，开发没有权限，业务服务极少，忙着写新业务，惊涛骇浪。在上 Kubernetes 的后半年，业务服务较少，偶然会阶段性被运维唤醒，问之“为什么你们的服务内存占用这么高，连忙查”。此时大家还在为新业务冲刺，猜想兴许是业务代码问题，但没有调整代码去尝试解决。在上 Kubernetes 的第二年，业务服务逐步增多，广泛减少了容器限额 Limits，呈现了好几个业务服务是内存小怪兽，因而如果不限度的话，服务适度占用会导致驱赶，因而反馈语也就变成了：“为什么你们的服务内存占用这么高，老被 OOM Kill，连忙查”。通过一段跨度较长的工夫的排查：狐疑业务代码（PProf）——狐疑其它代码（PProf）——狐疑 Go Runtime ——狐疑工具——狐疑环境，最终找出了起因并给出了解决方案。
12. 为什么容器内存占用居高不下，频频 OOM（续）
作者：煎鱼
通过外部探讨，因为种种原因（例如：Linux、Kubernetes 太低），咱们抉择了降级 Linux 版本，也就是 CentOS 8，这样子其内核版本就会达到至 4.x（cgroup 曾经强壮了许多，且在 4.5 cgroup v2 曾经 GA），相干问题曾经修复，并同步设置 cgroup.memory=nokmem 即可解决 / 防止相干问题。而在写下这篇文章时，咱们能够看到 kmem accounting 的不少问题都曾经被修复或提上日程，这对本次排查提供了相当大的便当，在确定问题的所在后依据 cgroup leak 沿着排查上来，根本都能看到大量的前人所经验过的“挣扎”，大家若有趣味，也能够跟着参考所提供的的链接做更一提高的深刻理解。但事实上，不论哪个 Linux 内核版本，都存在着或多或少的问题，须要做好适当的心理准备，否则就会遇到“没上容器时好好的”的困境，查起问题更麻烦。
13. 刨根问底——记一次 OOM 试验造成的电脑雪崩引发的思考
作者：码海
作者通过一个 OOM 试验引出了三个值得思考的问题：while (true) 与 cpu 负载的关系？产生 OOM 后 Ctrl+C 为啥无奈停止 Java 过程？主线程产生 OOM 后 Java 过程为啥不会进行运行？而后一一作了验证，并揭示读者看到书中的 demo 时最好能亲自去尝试一下，说不定能有新的发现！纸上得来终觉浅，绝知此事要躬行。碰到问题最好穷追猛打，这样咱们才会播种很多，提高很快！
14. 震惊！线上四台机器同一时间全副 OOM，到底产生了什么？
作者：码海
本文通过线上四台机器同时 OOM 的景象，来具体分析定位了产生问题的起因，能够看到咱们在利用某个库时首先要对这个库要有充沛的理解（上述 HttpClient 的创立不必单例显然是个问题），其次必要的网络常识还是须要的，所以要成为一个合格的程序员，不光对语言自身有所理解，还要对网络，数据库等也要有所涉猎，这些对排查问题以及性能调优等会有十分大的帮忙，再次，欠缺的监控十分重要，通过触发某个阈值提前告警，能够将问题扼杀在摇篮里！
15. 实战：OOM 后我如何剖析解决的
作者：jasonGeng88
对于内存泄露问题在第一次排查时，往往是有点手足无措的。咱们须要有正确的办法和伎俩，配上好用的工具，这样在解决问题时，能力熟能生巧。当然对 JAVA 内存的基础知识也是必不可少的，这时你定位问题的要害，不然就算工具通知你这块有错，你也不能定位起因。
16. 导致程序呈现 OOM 的因素，夜深人静的时候，程序 OOM 异样追踪
作者：兔兔七
作为 Java 程序员, 除了享受垃圾回收机制带来的便当外, 还深受 OOM(Out Of Memory) 的困惑和折磨。
作者故障定位中查到的 N 多 OOM 问题，起因大多为以下 3 类
1、线程池不治理式滥用
2、本地缓存滥用（如只须要应用 Node 的 id, 但将整个 Node 所有信息都缓存 )
3、非凡场景思考有余（如采纳单线程解决简单业务，环境震荡 + 多设施下积压工作暴增）
17.fastJson 与一起堆内存溢出 ’ 血案 ’
作者：landon30
场景：QA 同学反映登录不上服务器
排查过程：日志级别——JVM 命令级别——业余工具级别
剖析过程：察看数据——尝试重试——山重水复疑无路——源代码跟踪——问题初步总结
解决问题：为什么 cost 会那么大？方才咱们曾经根本必定是因为错误模式下的反序列化会导致 cost 字段会越来越大，那么也不至于上亿次吧? 这个我大略查了一下代码，很大几率是好友举荐模块和相干模块。相干代码须要较频繁的对于离线镜像反序列化或者存在相似心跳业务解决。解决办法很简略，就是肯定要记住 fastjson 序列化的时候要加上 IgnoreNonFieldGetter 就能够了。
18. 一次 Java 过程 OOM 的排查剖析（glibc 篇）
作者：挖坑的张师傅
遇到了一个 glibc 导致的内存回收问题，查找起因和试验的的过程是比拟有意思的，次要会波及到上面这些：
- Linux 中典型的大量 64M 内存区域问题
- glibc 的内存分配器 ptmalloc2 的底层原理
- 如何写一个自定义的 malloc hook 动态链接库 so
- glibc 的内存调配原理（Arena、Chunk 构造、bins 等）
- malloc_trim 对内存真正回收的影响
- gdb 的 heap 调试工具应用
- jemalloc 库的介绍与利用
19. 垃圾回收 - 实战篇
作者：geekoftaste
本文通过具体介绍了 JVM 参数及 GC 日志，OOM 产生的起因及相应的调试工具，置信读者应该把握了根本的 MAT，jvisualvm 这些工具排查问题的技巧，不过这些工具的介绍本文只是提到了一些皮毛，大家能够在再深刻理解相应工具的一些进阶技能，这能对本人排查问题等大有裨益！文中的例子大家能够去试验一下，批改一下参数看下会产生哪些神奇的景象，亲自动手做一遍能对排查问题的思路更加清晰哦。
20. 应用 XPocket 插件 JConsole 排查线上 OOM 异样案例
作者：鸠摩
XPocket 插件 JConsole 次要用于内存问题的排查，可能对堆中的 Eden、Survivor、Old 区以及堆外的 Metaspace、Code Cache 等区域进行察看。JConsole 可能排查 Java 过程内存的应用状况，特地是在排查过程中要进行屡次打印，比对数值来发现问题。如果要进一步在代码级别定位问题，还能够应用 XPocket 中的其它插件进行辅助定位。
OOM 问题品种繁多，在实在的业务场景中，环境也更加简单，须要具体问题具体分析，这就须要对各种 OOM 的产生原理足够理解和相熟。本文收录了蕴含大佬总结、源码解析以及大量的排查案例在内的 20 篇文章，旨在帮忙读者补充学习相干知识点，从实践和实战中学习办法，吸取教训，防止踩坑。
第三局部：测验篇
看到这里的你，曾经超过好多好多人啦～要不要来加入一下测验？看看你的学习效果如何！
小礼物：第一次答题就能拿到 90 分以上，并在社区的上述文章下有留言的小伙伴，将会取得 HeapDump 性能社区送出的 OOM 勋章一枚哦（每半个月统计一次）！
测验链接：https://ks.wjx.top/vj/trlUZ7d.aspx
奖品数量无限，先到先得哦～