(十)JVM成神路之线上故障排查、性能监控工具分析及各线上问题排错实战

引言

   经过前述九章的JVM知识学习后，咱们对于JVM的整体知识体系已经有了全面的认知。但前面的章节中，更多的是停留在理论上进行阐述，而本章节中则更多的会分析JVM的实战操作。
   当然，也正因为有了之前理论知识的支持，所以才能在线上环境去快速的定位故障问题、性能瓶颈，同时也能帮助咱们更加快捷的解决所遇的“难题”。

   线上排查、性能优化等概念也是面试过程中的“常客”，而对于线上遇到的“疑难杂症”，需要通过理性的思维去分析问题、排查问题、定位问题、解决问题，同时，如果解决掉所遇到的问题或瓶颈后，也可以在能力范围之内尝试最优解以及适当考虑拓展性。

在本章中会先讲明线上排查问题的思路，再接着会对于JVM常用的排查工具进行阐述，最后会对于JVM线上常遇的一些故障问题进行全面剖析。

一、JVM线上环境时常见故障与排查思路分析

   在开发过程中，如果遇到JVM问题时，通常都有各种各样的本地可视化工具支持查看。但开发环境中编写出的程序迟早会被部署在生产环境的服务器上，而线上环境偶尔也容易遇到一些突发状况，比如JVM在线上环境往往会出现以下几个问题：

• ①JVM内存泄漏。
• ②JVM内存溢出。
• ③业务线程死锁。
• ④应用程序异常宕机。
• ⑤线程阻塞/响应速度变慢。
• ⑥CPU利用率飙升或100%。

   当程序在线上环境发生故障时，就不比开发环境那样，可以通过可视化工具监控、调试，线上环境往往会“恶劣”很多，那当遇到这类问题时又该如何处理呢？首先在碰到这类故障问题时，得具备良好的排查思路，再建立在理论知识的基础上，通过经验+数据的支持依次分析后加以解决。

1.1、线上排查及其解决问题的思路

   相对而言，解决故障问题也好，处理性能瓶颈也罢，通常思路大致都是相同的，步骤如下：

• ①分析问题：根据理论知识+经验分析问题，判断问题可能出现的位置或可能引起问题的原因，将目标缩小到一定范围。
• ②排查问题：基于上一步的结果，从引发问题的“可疑性”角度出发，从高到低依次进行排查，进一步排除一些选项，将目标范围进一步缩小。
• ③定位问题：通过相关的监控数据的辅助，以更“细粒度”的手段，将引发问题的原因定位到精准位置。
• ④解决问题：判断到问题出现的具体位置以及引发的原因后，采取相关措施对问题加以解决。
• ⑤尝试最优解（非必须）：将原有的问题解决后，在能力范围内，且环境允许的情况下，应该适当考虑问题的最优解（可以从性能、拓展性、并发等角度出发）。

   当然，上述过程是针对特殊问题以及经验老道的开发者而言的，作为“新时代的程序构建者”，那当然得学会合理使用工具来帮助我们快速解决问题：

• ①摘取或复制问题的关键片段。
• ②打开百度或谷歌后粘贴搜索。
• ③观察返回结果中，选择标题与描述与自己问题较匹配的资料进入。
• ④多看几个后，根据其解决方案尝试解决问题。
• ⑤成功解决后皆大欢喜，尝试无果后“找人/问群”。
• ⑥“外力”无法解决问题时自己动手，根据之前的步骤依次排查解决。

前面给出了两套解决问题的步骤，面试/学习推荐前者，实际开发推荐后者，毕竟面试的时候人家问你怎么解决问题的，你总不能说靠百度。
同时还有关键一点要明白：“能够搜索出来的资料也是人写出来的，你为何不能成为写的那人呢”。

1.2、线上排查的方向

   通常情况下来说，系统部署在线上出现故障，经过分析排查后，最终诱发问题的根本原因无非在于如下几点：

• 应用程序本身导致的问题
  • 程序内部频繁触发GC，造成系统出现长时间停顿，导致客户端堆积大量请求。
  • JVM参数配置不合理，导致线上运行失控，如堆内存、各内存区域太小等。
  • Java程序代码存在缺陷，导致线上运行出现Bug，如死锁/内存泄漏、溢出等。
  • 程序内部资源使用不合理，导致出现问题，如线程/DB连接/网络连接/堆外内存等。
• 上下游内部系统导致的问题
  • 上游服务出现并发情况，导致当前程序请求量急剧增加，从而引发问题拖垮系统。
  • 下游服务出现问题，导致当前程序堆积大量请求拖垮系统，如Redis宕机/DB阻塞等。
• 程序所部署的机器本身导致的问题
  • 服务器机房网络出现问题，导致网络出现阻塞、当前程序假死等故障。
  • 服务器中因其他程序原因、硬件问题、环境因素（如断电）等原因导致系统不可用。
  • 服务器因遭到入侵导致Java程序受到影响，如木马病毒/矿机、劫持脚本等。
• 第三方的RPC远程调用导致的问题
  • 作为被调用者提供给第三方调用，第三方流量突增，导致当前程序负载过重出现问题。
  • 作为调用者调用第三方，但因第三方出现问题，引发雪崩问题而造成当前程序崩溃。

   万变不离其宗，虽然上述中没有将所有可能会发生问题的位置写到，但总的来说，发生问题排查时，也就是这几个大的方向，先将发生问题的大体定位，然后再逐步推导出具体问题的位置，从而加以解决。

二、Java提供的程序监控及性能调优工具

   碰到问题时，首先要做的就是定位问题。而一般定位问题是都会基于数据来进行，比如：程序运行日志、异常堆栈信息、GC日志记录、线程快照文件、堆内存快照文件等。同时，数据的收集又离不开监控工具的辅助，所以当JVM在线上运行过程中出现问题后，自然避免不了使用一些JDK自带以及第三方提供的工具，如：jps、jstat、jstack、jmap、jhat、hprof、jinfo、arthas等，接下来我们逐个认识这些工具。

jps、jstat、jstack、jmap、jhat、jinfo等命令都是安装JDK后自带的工具，它们的功能主要是调用%JAVA_HOME%/lib/tools.jar包里面的Java方法来实现的，所以如果你想自己打造一个属于自己的JVM监控系统，那在Java程序内部调用该jar包的方法即可实现。
JDK官方提供的JDK工具参考文档，当然，如果你不会使用这些工具，也可以通过参数：tool -help来查看它的使用方法，如：jps -help。

PS：对于JDK提供的这些工具了解的可以直接跳到第三阶段。

2.1、进程监控工具 - jps

   jps工具的主要作用是用来查看机器上运行的Java进程，类似于Linux系统的ps -aux|grep java命令。jps工具也支持查看其他机器的Java进程，命令格式如下：

jps [ options ] [ hostid ]
查看指令的用法：jps -help

其中[options]主要有-q、-m、-l、-v、-V几个选项：

• jps -q：查看机器所有运行的Java进程，但只显示进程号（lvmid）。
• jps -m：~，只显示传递给main方法的参数。
• jps -l：~，只显示运行程序主类的包名，或者运行程序jar包的完整路径。
• jps -v：~，单独显示JVM启动时，显式指定的参数。
• jps -V：~，显示主类名或者jar包名。

其中[hostid]是用来连接其他机器查看Java进程的远程ID。

JPS工具实际使用方式：jps [pid]。

2.2、配置信息查看工具 - jinfo

   jps工具主要用于实时查看JVM的运行参数，也可以在运行时动态的调整一些参数。命令格式如下：

jinfo [ option1 ] [ option2 ]
查看指令的用法：jinfo -help / jinfo -h

其中[option1]可选项如下：

• ：第一个参数不写，默认输出JVM的全部参数和系统属性。
• -flag ：输出与指定名称对应的所有参数，以及参数值。
• -flag [+|-]：开启或者关闭与指定名称对应的参数。
• -flag =：设置与指定名称对应参数的值。
• -flags：输出JVM全部的参数。
• -sysprops：输出JVM全部的系统属性。

其中[option2]可选项如下：

• ：对应的JVM进程ID（必需参数），指定一个jinfo要操作的Java进程。
• executable ：输出打印堆栈跟踪的核心文件。
• [server-id@]：远程操作的地址。
  • server-id：远程debug服务的进程ID；
  • remote server IP/hostname：远程debug服务的主机名 或 IP地址；

Jinfo工具实际使用方式：jinfo -flags [pid]。

PS：对于每个不同选项的效果就不再演示了，感兴趣的小伙伴可以自行在本地开个Java进程，然后使用上述的选项进行调试观察。

2.3、信息统计监控工具 - jstat

   jstat工全称为“Java Virtual Machine statistics monitoring tool”，该工具可以利用JVM内建的指令对Java程序的资源以及性能进行实时的命令行的监控，监控范围包含：堆空间的各数据区、垃圾回收状况以及类的加载与卸载状态。

命令格式：jstat - [-t] [-h] [ []]

其中每个参数的释义如下：

• [option]：监控参数选项。
• -t：在输出结果中加上Timestamp列，显示系统运行的时间。
• -h：可以在周期性数据输出的时候，指定间隔多少行数据后输出一次表头。
• vmid：Virtual Machine ID虚拟ID，也就是指定一个要监控的Java进程ID。
• interval：每次执行的间隔时间，默认单位为ms。
• count：用于指定输出多少条数据，默认情况下会一直输出。

执行命令jstat -option后，可以看到存在很多选项，如下：

• -class：输出类加载ClassLoad相关的信息。
• -compiler：显示与JIT即时编译相关的信息。
• -gc：显示与GC相关的信息。
• -gccapacity：显示每个分代空间的容量以及使用情况。
• -gcmetacapacity：输出元数据空间相关的信息。
• -gcnew：显示新生代空间相关的信息。
• -gcnewcapacity：显示新生代空间的容量大小以及使用情况。
• -gcold：输出年老代空间的信息。
• -gcoldcapacity：输出年老代空间的容量大小以及使用情况。
• -gcutil：显示垃圾回收信息。
• -gccause：和-gcutil功能相同，但是会额外输出最后一次或本次GC的诱因。
• -printcompilation：输出JIT即时编译的方法信息。

所以jstat的实际使用方式如下：

jstat -gc -t -h30 9895 1s 300
-gc：监控GC的状态
-t：显示系统运行的时间
-h30：间隔30行数据，输出一次表头
9895：Java进程ID
1s：时间间隔
300：本次输出的数据行数

最终执行效果如下：

jstat工具-命令行监控

统计列各字段含义如下：

字段名称	字段释义
Timestamp	系统运行的时间
S0C	第一个Survivor区的总容量大小
S1C	第二个Survivor区的总容量大小
S0U	第二个Survivor区的已使用大小
S1U	第二个Survivor区的已使用大小
EC	Eden区的总容量大小
EC	Eden区的已使用大小
OC	Old区的总容量大小
OU	Old区的已使用大小
MC	Metaspace区的总容量大小
MU	Metaspace区的已使用大小
CCSC	CompressedClassSpace空间的总大小
CCSU	CompressedClassSpace空间的已用大小
YGC	从程序启动到采样时，期间发生的新生代GC次数
YGCT	从程序启动到采样时，期间新生代GC总耗时
FGC	从程序启动到采样时，期间发生的年老代GC次数
FGCT	从程序启动到采样时，期间年老代GC总耗时
GCT	从程序启动到采样时，程序发生GC的总次数

而除此之外，[options]指定其他选项时，也会出现不同的统计列字段，如下：

字段名称	字段释义
S0	第一个Survivor区的使用率（S0U/S0C）
S1	第二个Survivor区的使用率（S1U/S1C）
E	Eden区的使用率（EU/EC）
O	Old区的使用率（OU/OC）
M	Metaspace区的使用率（MU/MC）
CCS	CompressedClassSpace区的使用率（CCSU/CCSC）
NGCMN	新生代空间初始容量
NGCMX	新生代空间最大容量
S0CMN	第一个Survivor区的初始容量
S0CMX	第一个Survivor区的最大容量
S1CMN	第二个Survivor区的初始容量
S1CMX	第二个Survivor区的最大容量
OGCMN	年老代空间初始容量
OGCMX	年老代空间最大容量
MCMN	元数据空间初始容量
MCMX	元数据空间最大容量
CCSMN	类压缩空间初始容量
CCSMX	类压缩空间最大容量
TT	对象晋升的最小年龄阈值
MTT	对象晋升的最大年龄阈值
DSS	期望的Survivor区总大小

CCS全称为“CompressedClassSpace”，主要是指存储类压缩指针的空间，具体可以看这个。

除开堆空间和GC相关的统计列信息之外，jstat工具还可以类加载与卸载的状态、监控JIT即时编译，执行jstat -class [pid]、jstat -compiler [pid]指令即可，效果如下：

jstat工具监控类信息、JIT信息

类加载与卸载相关的监控数据统计列字段解读：

字段名称	字段释义
Loaded	JVM已经装载的类数量
Bytes	已装载的类占用字节数大小
Unloaded	已经卸载的类数量
Bytes	已卸载的类占用字节数大小
Time	卸载和装载类共耗时

JIT即时编译相关的监控数据统计列字段解读：

字段名称	字段释义
Compiled	编译任务执行的总次数
Failed	编译任务执行失败的次数
Invalid	编译任务执行失效的次数
Bytes	已卸载的类占用字节数大小
Time	所有编译任务的总耗时
FailedType	最后一个编译失败的任务类型
FailedMethod	最后一个编译失败的任务所在的类及方法

对于jstat工具执行不同指令后，每个统计列的含义都已在上述中解释清楚，如若之后在线上环境采用jstat工具排查性能瓶颈时，对于不理解的统计列皆可参考如上释义。

2.4、堆内存统计分析工具 - jmap

   jmap是一个多功能的工具，主要是用于查看堆空间的使用情况，通常会配合jhat工具一起使用，它可以用于生成Java堆的Dump文件。但除此之外，也可以查看finalize队列、元数据空间的详细信息，Java堆中对象统计信息，如每个分区的使用率、当前装配的GC收集器等。

命令格式：> jmap [ option1 ] [ option2 ]

其中[option1]可选项有：

• [no option]：查看进程的内存映像信息，与Solaris pmap类似。
• -heap：显示Java堆空间的详细信息。
• -histo[:live]：显示Java堆中对象的统计信息。
• -clstats：显示类加载相关的信息。
• -finalizerinfo：显示F-Queue队列中等待Finalizer线程执行finalizer方法的对象。
• -dump:：生成堆转储快照。
• -F：当正常情况下-dump和-histo执行失效时，前面加-F可以强制执行。
• -help：显示帮助信息。
• -J：指定传递给运行jmap的JVM参数。

其中[option2]与jinfo工具的相差无几，可选项如下：

• ：对应的JVM进程ID（必需参数），指定一个jinfo要操作的Java进程。
• executable ：输出打印堆栈跟踪的核心文件。
• [server-id@]：远程操作的地址。
  • server-id：远程debug服务的进程ID；
  • remote server IP/hostname：远程debug服务的主机名 或 IP地址；

jmap工具实际使用方式：jmap -clstats [pid]或jmap -dump:live,format=b,file=Dump.phrof [pid]等。
堆快照导出命令解析：
live：导出堆中存活对象快照；format：指定输出格式；file：指定输出的文件名及其格式（.dat、.phrof等格式）。

当然，具体的每个选项的效果也不再演示，大家感兴趣可以自行调试后观测。

不过值得一提的是：大部分JDK提供的工具与JVM通信方式都是通过的Attach机制实现的，该机制可以针对目标JVM进程进行一些操作，比如获取内存Dump、线程Dump、类信息统计、动态加载Agent、动态设置JVM参数、打印JVM参数、获取系统属性等。有兴趣可以去深入研究一下，具体源码位置位于：com.sun.tools.attach包，里面存在一系列Attach机制相关的代码。

在最后对于histo选项做个简单调试，histo选项主要作用是打印堆空间中对象的统计信息，包括对象实例数、内存空间占用大小等。因为在histo:live前会进行FullGC，所以带上live只会统计存活对象。因此，不加live的堆大小要大于加live堆的大小（因为带live会强制触发一次FullGC），如下：

jmap -histo:live对象统计信息

上图中，class name是对象的类型，但有些是缩写，对象的缩写类型与真实类型对比如下：

缩写类型	B	C	D	F	I	J	Z	[	L+类型
真实类型	byte	char	double	float	int	long	boolean	数组	其他对象

2.5、堆内存快照分析工具 - jhat

   jhat工具一般配合jmap工具使用，主要用于分析jmap工具导出的Dump文件，其中也内嵌了一个微型的HTTP/HTML服务器，所以当jhat工具分析完Dump文件后，可以支持在浏览器中查看分析结果。
    不过在线上环境中一般不会直接使用jhat工具对Dump文件进行解析，因为jhat解析Dump文件，尤其是大体积的Dump时，是一个非常耗时且占用硬件资源的过程。所以为了防止占用服务器过多的资源，通常都会将Dump文件copy到其他机器或本地中分析。

    不过话说回来，到了本地一般也不会使用jhat，因为分析之后生成的结果通过浏览器观察时很难看，一般都会选择MAT（Eclipse Memory Analyzer）、IBM HeapAnalyzer、VisualVM、Jprofile等工具。

jhat命令格式：jhat [-stack ] [-refs ] [-port ] [-baseline ] [-debug ] [-version] [-h|-help]

jhat的这条指令有点长，其中可以选择填写很多参数，释义如下：

• -stack：默认为true，是否开启对象分配调用栈跟踪。
• -refs：默认为true，是否开启对象引用跟踪
• -port：默认为7000，设置jhat工具浏览器访问的端口号。
• -baseline：指定基准堆转储Dump文件，在两个Dump文件中有相同对象时，会被标记为旧对象，不同的对象会被标记为新对象，主要用于对比分析两个不同的Dump文件。
• -debug：默认为0，设置debug级别，0表示不输出调试信息，值越大信息越详细。
• -version：显示版本信息。
• -help：查看帮助信息。
• ：要分析的Dump文件。
• -J：jhat工具实际上也是启动了一个JVM进程来执行的，可以通过-J指令为该JVM传递一些JVM参数，如：-J-Xmx128m这类的。

jhat实际应用方式：jhat HeapDump.dat，效果如下：

> jmap -dump:live,format=b,file=HeapDump.dat 7452
Dumping heap to HeapDump.dat ...
Heap dump file created

> jhat HeapDump.dat
Reading from HeapDump.dat...
Dump file created Wed Mar 09 14:50:06 CST 2022
Snapshot read, resolving...
Resolving 7818 objects...
Chasing references, expect 1 dots.
Eliminating duplicate references.
Snapshot resolved.
Started HTTP server on port 7000
Server is ready.

上述过程中，首先通过jmap工具导出了Java堆的内存dump文件，紧接着使用jhat工具对导出的dump文件进行分析，分析完成后可以打开浏览器，输入http://localhost:7000查看jhat分析后生成的结果，如下：

jhat-浏览器分析结果界面

其中提供了不少选项，从上至下分别为：

• ①按照包路径查看不同类的具体对象实例。
• ②查看堆中的所有Roots节点的集合。
• ③查看所有类的对象实例数量（包括了JVM自身的类）。
• ④查看所有类的对象实例数量（除去了JVM自身的类）。
• ⑤查看Java堆中实例对象的统计直方图（和jmap的对象统计信息差不多）。
• ⑥查看JVM的finalizer相关信息。
• ⑦通过jhat工具提供的QQL对象查询语言获取指定对象的实例信息。
  • QQL具体的语法可以直接访问http://localhost:7000/oqlhelp查看。

其实本质上而言，jhat提供的浏览器界面也不怎么方便我们去排除问题。因此，实际分析堆Dump文件时，通常都会采用一些更为直观方便的工具，如：MAT、Jconsole、IBM HeapAnalyzer、visualVm等。

2.6、堆栈跟踪工具 - jstack

   jstack工具主要用于捕捉JVM当前时刻的线程快照，线程快照是JVM中每条线程正在执行的方法堆栈集合。在线上情况时，生成线程快照文件可以用于定位线程出现长时间停顿的原因，如线程死锁、死循环、请求外部资源无响应等等原因导致的线程停顿。

   当线程出现停顿时，可以通过jstack工具生成线程快照，从快照信息中能查看到Java程序内部每条线程的调用堆栈情况，从调用堆栈信息中就可以清晰明了的看出：发生停顿的线程目前在干什么，在等待什么资源等。
   同时，当Java程序崩溃时，如果配置好了参数，生成了core文件，咱们也可以通过jstack工具从core文件中提取Java虚拟机栈相关的信息，从而进一步定位程序崩溃的原因。

jstack工具命令格式：jstack [-F] [option1] [option2]

其中[option1]可选项为：

• -l：除开显示堆栈信息外，额外输出关于锁相关的附加信息（用于排查死锁问题）。
• -m：如果线程调用到本地方法栈中的本地方法，也显示C/C++的堆栈信息。

其中[option2]可选项如下：

• ：对应的JVM进程ID（必需参数），指定一个jinfo要操作的Java进程。
• executable ：输出打印堆栈跟踪的核心文件。
• [server-id@]：远程操作的地址。
  • server-id：远程debug服务的进程ID；
  • remote server IP/hostname：远程debug服务的主机名 或 IP地址；

jstack工具实际使用方式：jstack -l [pid]。

同时，jstack工具的-F参数与jmap的作用相同，当正常执行失效时，加上-F可以强制执行jstack指令。

最后，jstack工具导出的Dump日志值得留意的状态：

状态	释义
Deadlock	线程出现死锁
Runnable	线程正在执行中
Waiting on condition	线程等待资源
Waiting on monitor entry	线程等待获取监视器锁
Suspended	线程暂停
Object.wait()、TIMED_WAITING	线程挂起
Blocked	线程阻塞
Parked	线程停止

2.7、JVM排查工具小结

   上述分析的工具都是JDK自带的工具，每个不同的工具都拥有各自的作用，可以在不同维度对JVM运行时的状况进行监控，也能够帮助我们在线上环境时快速去定位排除问题。但除开JDK官方提供的一些工具之外，也有非常多第三方工具用起来非常顺手，如arthas、jprofilter、perfino、Yourkit、Perf4j、JProbe、MAT、Jconsole、visualVm等，这些工具往往都比前面分析提到的那些JDK工具更实用且功能更加强大。

三、JVM线上故障问题“大合集”与排查实战

   程序上线后，线上遇到突发状况无疑是一件令人头疼的事情，但作为一位合格的开发者，不是仅会敲出一手流利的代码就足够了，线上排错这项技能也额外重要。但线上排错的能力强弱更取决于经验的丰富与否，丰富的实操经验与理论知识储备+理性的排错思路才是线上排查中最为重要的。

   接下来会对线上环境中发生最为频繁的故障问题进行全方位剖析及实战，如JVM内存泄漏、内存溢出、业务线程死锁、应用程序异常宕机、线程阻塞/响应速度变慢、CPU利用率飙升或100% 等。

3.1、线上排查的“前夕”

   在排查问题时，诱发问题的原因也有可能来自于上下游系统。因此，当出现问题时，首先得定位出现问题的节点，然后针对该节点进行排错。但无论是哪个节点（Java应用、DB、上下游Java系统等），出现问题的原因无非就几个方向：代码、CPU、磁盘、内存以及网络问题，所以遇到线上问题时，合理采用OS与JVM提供的工具（如df、free、top、jstack、jmap、ps等），将这些方面依次排查一遍即可。

不过需要额外注意：JVM提供的大部分工具在使用时会影响性能，所以如果你的程序是以单机的模式部署，那最好在排查问题之前做好流量迁移（改DNS、Nginx配置等）。如果你的程序是以集群模式部署，那么可以将其中一台机器隔离出来，用于保留现场，也为了更方便的调试问题。
同时，如果线上的机器已经无法提供正常服务，那么在排查问题之前首先要做到的是“及时止损”，可以采用版本回滚、服务降级、重启应用等手段让当前节点恢复正常服务。

3.2、JVM内存溢出（OOM）

先来理解一下内存溢出：

举例：一个木桶只能装40L水，但此时往里面倒入50L水，多出来的水会从桶顶溢出。换到程序的内存中，这种情况就被称为内存溢出。

   内存溢出（OOM）在线上排查中是一个比较常见的问题，同时在Java内存空间中，也会有多块区域会发生OOM问题，如堆空间、元空间、栈空间等，具体可参考前面的深入理解JVM运行时数据区这一章节。通常情况下，线上环境产生内存溢出的原因大致上有三类：

• ①为JVM分配的内存太小，不足以支撑程序正常执行时的数据增长。
• ②编写的Java程序内部存在问题、有Bug，导致GC回收速率跟不上分配速率。
• ③自己的代码或引入的第三方依赖存在内存溢出问题，导致可用内存不足。

上述②③问题皆是由于编写的Java程序代码不严谨导致的OOM，由于Java内存中产生了大量垃圾对象，导致新对象没有空闲内存分配，从而产生的溢出。

在排查OOM问题时，核心是：哪里OOM了？为什么OOM了？怎么避免出现的OOM？
同时，在排查过程中，应当要建立在数据的分析之上，也就是指Dump数据。
获取堆Dump文件方式有两种：
①启动时设置-XX:HeapDumpPath，事先指定OOM出现时，自动导出Dump文件。
②重启并在程序运行一段时间后，通过工具导出，如前面的jmap或第三方工具。

3.2.1、Java线上OOM排查实操

模拟案例如下：

// JVM启动参数：-Xms64M -Xmx64M -XX:+HeapDumpOnOutOfMemoryError 
// -XX:HeapDumpPath=/usr/local/java/java_code/java_log/Heap_OOM.hprof
public class OOM {
    // 测试内存溢出的对象类
    public static class OomObject{}
    
    public static void main(String[] args){
        List OOMlist = new ArrayList<>();
        // 死循环：反复往集合中添加对象实例
        for(;;){
            OOMlist.add(new OomObject());
        }
    }
}

在Linux上，先以后台运行的方式启动上述的Java程序：

root@localhost ~]# java -Xms64M -Xmx64M -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/java/java_code/java_log/Heap_OOM.hprof OOM &
[1] 78645

等待一段时间后，可以看到在/usr/local/java/java_code/java_log/目录下，已经自动导出了堆Dump文件，接下来我们只需要把这个Dump文件直接往Eclipse MAT(Memory Analyzer Tool)工具里面一丢，然后它就能自动帮你把OOM的原因分析出来，然后根据它分析的结果改善对应的代码即可。

其实上述这个案例中，你运行之后过一会儿就会给你输出一句OOM异常信息：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java.util.Arrays.copyOf(Arrays.java:3210)
    at java.util.Arrays.copyOf(Arrays.java:3181)
    at java.util.ArrayList.grow(ArrayList.java:261)
    at java.util.ArrayList.ensureExplicitCapacity(ArrayList.java:235)
    at java.util.ArrayList.ensureCapacityInternal(ArrayList.java:227)
    at java.util.ArrayList.add(ArrayList.java:458)
    at OOM.main(OOM.java:13)

   在最后面都已经明确告诉了你，导致OOM的代码位置，因此这个案例没有太大的参考价值，其实也包括大部分他人的OOM排查过程，相对来说参考价值都并非太大，因为排查OOM问题时只需要自己具备理性的思维，步骤都大概相同的，所以接下来重点阐明排查OOM的思路即可。

---

线上OOM问题排查思路：

• ①首先获取Dump文件，最好是上线部署时配置了，这样可以保留第一现场，但如若未配置对应参数，可以调小堆空间，然后重启程序的时候重新配置参数，争取做到“现场”重现。
• ②如果无法通过配置参数获得程序OOM自然导出的Dump文件，那则可以等待程序在线上运行一段时间，并协调测试人员对各接口进行压测，而后主动式的通过jmap等工具导出堆的Dump文件（这种方式没有程序自动导出的Dump文件效果好）。
• ③将Dump文件传输到本地，然后通过相关的Dump分析工具分析，如JDK自带的jvisualvm，或第三方的MAT工具等。
• ④根据分析结果尝试定位问题，先定位问题发生的区域，如：确定是堆外内存还是堆内空间溢出，如果是堆内，是哪个数据区发生了溢出。确定了溢出的区域之后，再分析导致溢出的原因（后面会列出一下常见的OOM原因）。
• ⑤根据定位到的区域以及原因，做出对应的解决措施，如：优化代码、优化SQL等。

3.2.2、线上内存溢出问题小结

   Java程序在线上出现问题需要排查时，内存溢出问题绝对是“常客”，但通常情况下，OOM大多是因为代码问题导致的，在程序中容易引发OOM的情况：

• ①一次性从外部将体积过于庞大的数据载入内存，如DB读表、读本地报表文件等。
• ②程序中使用容器(Map/List/Set等)后未及时清理，内存紧张而GC无法回收。
• ③程序逻辑中存在死循环或大量循环，或单个循环中产生大量重复的对象实例。
• ④程序中引入的第三方依赖中存在BUG问题，因此导致内存出现故障问题。
• ⑤程序中存在内存溢出问题，一直在蚕食可用内存，GC无法回收导致内存溢出。
• ⑥第三方依赖加载大量类库，元空间无法载入所有类元数据，因而诱发OOM。
• ⑦........

   上述都是程序内代码引发OOM的几种原因，在线上遇到这类情况时，要做的就是定位问题代码，而后修复代码后重新上线即可。同时，除开代码诱发的OOM情况外，有时因为程序分配的内存过小也会引发OOM，这种情况是最好解决的，重新分配更大的内存空间就能解决问题。

不过Java程序中，堆空间、元空间、栈空间等区域都可能出现OOM问题，其中元空间的溢出大部分原因是由于分配空间不够导致的，当然，也不排除会存在“例外的类库”导致OOM。真正意义上的栈空间OOM在线上几乎很难遇见，所以实际线上环境中，堆空间OOM是最常见的，大部分需要排查OOM问题的时候，几乎都是堆空间发生了溢出。

3.3、JVM内存泄漏

先来理解一下内存泄漏：

举例：一个木桶只能装40L水，但此刻我往里面丢块2KG的金砖，那该水桶在之后的过程中，最多只能装38L的水。此时这种情况换到程序的内存中，就被称为内存泄漏。
PS：不考虑物体密度的情况，举例说明不要死磕！

   内存泄漏和内存溢出两个概念之间，总让人有些混淆，但本质上是两个完全不同的问题。不过在发生内存溢出时，有可能是因为内存泄漏诱发的，但内存泄漏绝对不可能因为OOM引发。

线上的Java程序中，出现内存泄漏主要分为两种情况：

• ①堆内泄漏：由于代码不合理导致内存出现泄漏，如垃圾对象与静态对象保持着引用、未正确的关闭外部连接等。
• ②堆外泄漏：申请buffer流后未释放内存、直接内存中的数据未手动清理等。

   而一般在线上排查时并不能直接检测出内存泄漏问题，因为是否存在内存溢出问题除非监控了堆空间的对象变化，否则在正常情况下很难发觉。因此，通常情况下线上遇到泄漏问题时，都是伴随着OOM问题出现的，也就是：

排查OOM问题时，发现是由于内存泄漏一直在蚕食可用的空闲内存，最终导致新对象分配时没有空闲内存可用于分配，而造成的内存溢出。

3.3.1、JVM内存泄漏排查小实战

内存溢出的模拟案例：

// JVM启动参数：-Xms64M -Xmx64M -XX:+HeapDumpOnOutOfMemoryError 
// -XX:HeapDumpPath=/usr/local/java/java_code/java_log/Heap_MemoryLeak.hprof
// 如果不做限制，想要观测到内存泄漏导致OOM问题需要很长时间。
public class MemoryLeak {
    // 长生命周期对象，静态类型的root节点
    static List