JVM-OOM排查思路

JVM 内存溢出排查思路：

一般来讲，我们会先用 free 命令先来检查一发内存的各种情况,

堆内内存

JVM 中的内存不足，OOM 大致可以分为以下几种：

① Exception in thread "main" java.lang.OutOfMemoryError: unable to create new native thread
这个意思是没有足够的内存空间给线程分配 Java 栈，基本上还是线程池代码写的有问题，比如说忘记 shutdown，所以说应该首先从代码层面来寻找问题，使用 jstack 或者 jmap。
如果一切都正常，JVM 方面可以通过指定 Xss 来减少单个 thread stack 的大小。另外也可以在系统层面，可以通过修改 /etc/security/limits.confnofile 和 nproc 来增大 os 对线程的限制。

② Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
这个意思是堆的内存占用已经达到 -Xmx 设置的最大值，应该是最常见的的 OOM 错误了。
解决思路仍然是先应该在代码中找，怀疑存在内存泄漏，通过 jstack 和 jmap 去定位问题。如果说一切都正常，才需要通过调整 Xmx 的值来扩大内存。

③ Caused by: java.lang.OutOfMemoryError: Meta space
这个意思是元数据区的内存占用已经达到 XX:MaxMetaspaceSize 设置的最大值，排查思路和上面的一致，参数方面可以通过 XX:MaxPermSize 来进行调整

堆外内存

首先堆外内存溢出表现就是物理常驻内存增长快，报错的话视使用方式都不确定。
如果由于使用 Netty 导致的，那错误日志里可能会出现 OutOfDirectMemoryError 错误，如果直接是 DirectByteBuffer，那会报 OutOfMemoryError: Direct buffer memory。
堆外内存溢出往往是和 NIO 的使用相关，一般我们先通过 pmap 来查看下进程占用的内存情况 pmap -x pid | sort -rn -k3 | head -30，这段意思是查看对应 pid 倒序前 30 大的内存段。这边可以再一段时间后再跑一次命令看看内存增长情况，或者和正常机器比较可疑的内存段在哪里
我们如果确定有可疑的内存端，需要通过 gdb 来分析 gdb --batch --pid {pid} -ex "dump memory filename.dump {内存起始地址} {内存起始地址+内存块大小}"。
获取 dump 文件后可用 heaxdump 进行查看 hexdump -C filename | less，不过大多数看到的都是二进制乱码。NMT 是 Java7U40 引入的 HotSpot 新特性，配合 jcmd 命令我们就可以看到具体内存组成了.
需要在启动参数中加入 -XX:NativeMemoryTracking=summary 或者 -XX:NativeMemoryTracking=detail，会有略微性能损耗。一般对于堆外内存缓慢增长直到爆炸的情况来说，可以先设一个基线 jcmd pid VM.native_memory baseline。然后等放一段时间后再去看看内存增长的情况，通过 jcmd pid VM.native_memory detail.diff(summary.diff) 做一下 summary 或者 detail 级别的 diff, jcmd 分析出来的内存十分详细，包括堆内、线程以及 GC（所以上述其他内存异常其实都可以用 nmt 来分析），这边堆外内存我们重点关注 Internal 的内存增长，如果增长十分明显的话那就是有问题了。

GC排查

我们是通过 GC 日志来排查问题的，在启动参数中加上 -verbose:gc，-XX:+PrintGCDetails，-XX:+PrintGCDateStamps，-XX:+PrintGCTimeStamps 来开启 GC 日志。
常见的 Young GC、Full GC 日志含义在此就不做赘述了。针对 GC 日志，我们就能大致推断出 youngGC 与 Full GC 是否过于频繁或者耗时过长，从而对症下药。

① youngGC 过频繁
youngGC 频繁一般是短周期小对象较多，先考虑是不是 Eden 区/新生代设置的太小了，看能否通过调整 -Xmn、-XX:SurvivorRatio 等参数设置来解决问题。如果参数正常，但是 youngGC 频率还是太高，就需要使用 Jmap 和 MAT 对 dump 文件进行进一步排查了。

② youngGC 耗时过长
耗时过长问题就要看 GC 日志里耗时耗在哪一块了。以 G1 日志为例，可以关注 Root Scanning、Object Copy、Ref Proc 等阶段。Ref Proc 耗时长，就要注意引用相关的对象。Root Scanning 耗时长，就要注意线程数、跨代引用。Object Copy 则需要关注对象生存周期。而且耗时分析它需要横向比较，就是和其他项目或者正常时间段的耗时比较。

③触发 Full GC
G1 中更多的还是 mixedGC，但 mixedGC 可以和 youngGC 思路一样去排查。

这是我们排查过程中从不同的角度进行思考分析 ， 根据不同的原因进行分析