Java应用OOM问题的排查过程

导读

本文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。

前言：此文记录最近一例Java应用OOM问题的排查过程，希望可以给遇到类似问题的同学提供参考。在本地集团，大多数情况下Java堆的大小会设置为容器规格的50%～70%，但如果你设置为50%时还是遇到了OS OOM的问题，会不会无法忍受进而想要知道这是为什么？没错，我也有一样的好奇。

背景

某核心应用的负责同学反馈应用存在少量机器OOM被OS kill的问题。看sunfire监控信息，的确如此。

初步收集到的信息：

容器内存=8G，Java 11，G1 GC=4G，MaxDirectMemorySize=1G。详见下图：

业务同学已经做过Java dump，可以看到堆外对象几乎没有，堆内的使用量也不大，<3G。上机器查看Java进程的内存使用量的确很大：

通过目前掌握到的信息来看，4G（Java堆）+1G（堆外）+512M（元空间）+250M（CodeCache）+其它，离6.8G还是有不少差距，无法简单的明确原因，需要深入排查分析了。

问题结论

省流版

中间件中多个不同的ClassLoader加载了多个netty的io.netty.buffer.PooledByteBufAllocator，每一个都有1G的内存配额，所以存在实际使用的堆外内存超出1G限制的问题。

通过Arthas可以看到存在这个类的7个不同的实例：

而其中rocketmq-client的这一个，已经基本用完1G的内存（其它几个使用量大多在100多M的样子）：

详细版

中间件中多个不同的ClassLoader加载了多个netty的io.netty.buffer.PooledByteBufAllocator，每个Allocator都用自己的计数器在限制堆外内存的使用量，这个限制值大多数情况下取值至MaxDirectMemorySize，所以会存在无法限制堆外内存使用量在1G以内的问题。（这个设计是否合理，还请中间件的同学帮忙补充了）

这个应用是饿了么弹内的应用，io.netty.buffer.PooledByteBufAllocator，有7个ClassLoader加载了它，分别是：

sentinel's ModuleClassLoader、rocketmq-client's ModuleClassLoader、tair-plugin's ModuleClassLoader、hsf's ModuleClassLoader、XbootModuleClassLoader、pandora-qos-service's ModuleClassLoader、ele-enhancer's ModuleClassLoader。

相比弹内应用的4个（数据来自淘天集团的核心应用ump2，如下图），多了3个。

在Java8，以及Java11中（JVM参数设置了-Dio.netty.tryReflectionSetAccessible=true过后），netty会直接使用unsafe的方法申请堆外内存，不通过Java的DirectMemory分配API，所以通过监控看不到堆外内存的占用量，也不受JVM MaxDirectMemorySize的管控。

查看DirectByteBuffer实现代码可以发现，它限制MaxDirectMemorySize的方法是在Java层（代码标记处1），实际上在JVM底层是没有任何限制的，netty是直接用了这里代码标记处2的API分配内存。

排查过程

1.1.通过NativeMemoryTracking看Native内存的占用分布

通过在JVM参数上加上-XX:NativeMemoryTracking=detail，就可以打印出详细的内存分类的占用信息了，观察了一整天，发现主要的可疑变化是在Other部分，即堆外的部分，如下图。（ Java NMT的详细使用可以参考相应的技术文章）

明明是限制的堆外1G，怎么超过了这么多。再多观察一会，发现它还会继续缓慢上涨的，最高达到接近1.5GB。这就和最开始查看Java进程的RSS占用对上了。

1.2.native内存泄漏了吗

JVM使用什么native分配器

通过查看机器上安装的JDK的信息，可以看到使用的是jemalloc的内存分配器。是不是它有泄漏、内存碎片、归还不及时的问题？

网上搜索，发现的有一篇文章讲的场景和我们这里的有一些类似。（https://blog.csdn.net/liulilittle/article/details/137535634）

尝试重新下载jemalloc的源码，并进行其参数的调整：

export MALLOC_CONF="dirty_decay_ms:0,muzzy_decay_ms:0"

观察发现内存的占用量有少量的下降，但还是会超过1个G，看起来核心问题不在这里。

谁在分配内存

同时还通过perf工具监控了下调用内存分配的调用栈，想看看有什么线索没有，然而并没有什么线索。毕竟这个内存的增长比较缓慢，perf也不可能抓太长时间了，遂放弃这个思路。

sudo perf probe -x /opt/taobao/install/ajdk11_11.0.23.24/lib/libjemalloc.so.2 malloc

sudo perf record -e probe_libjemalloc:malloc -p `pidof java` -g -- sleep 10

内存里面装了什么

通过 sudo pmap -x `pidof java` | sort -k 3 -n 命令查看进程的所有内存块信息，如下图示：

排除最大的4G的这一个（这是Java堆），以及内存标志带x的两个（可执行代码标志，那是CodeCache），把其它的块都dump下来，看看里面都放了啥，有没有什么不平凡的。

使用gdb命令：gdb --batch --pid `pidof java` -ex "dump memory mem1.log 0x7f0109800000 0x7f0109800000+0x200000"

然后将dump下的内存以字符串的方式输出观察下：cat mem1.log | strings

如图所示，发现里面大量的内容都和RocketMQ有关。不过我发现我早率了，这些dump内容我看了快一天，根本没有发现什么不太对的地方，看起来都是正常的占用。（不过明显能看出来这里面存了一堆消费者信息，表达的比较冗余）

求助JVM专家

还真是从入门到放弃，到这个时候已经没啥信心啦。遂求助于JVM的专家毛亮，他给了大的方向，一是这里不太可能有native的内存泄漏，二是既然怀疑是堆外，把堆外内存减少一点看看情况，明确下是不是native内存分配器的回收特性就是这样。往往native的内存分配器都有自己的管理策略，他会有自己的回收拐点，比应用看到的高一点是合理的。

的确，那么接下来的策略就是把MaxDirectMemeorySize调低到512M观察下效果吧。

1.3.堆外内存调小影响业务了

在堆外内存从1G调小到512M过后，过了个周末，周一的时候业务同学就反馈，调小遇到问题了，存在MQ消息消费不及时而导致消息挤压的问题。结合之前看到的native内存的信息，突然想到，MQ客户端一定是占用了超过512M的内存，内心里出现了两个问题：

1.MQ底层依赖netty，那么netty实际使用的内存是多少？以及这个内存占用量和native的堆外占用量是什么关系？

2.为啥Java的DirectMemory占用这么少，netty的内存占用似乎并没有被看到，这是怎么回事？

带着这两个问题，查看了netty内存管理的核心类 io.netty.buffer.PooledByteBufAllocator，以及机器上启动过程中打印出的信息。

结合这里面涉及的另一个核心类io.netty.util.internal.PlatformDependent，大概明白了这里面的逻辑，netty是直接使用（是有前提条件的，但这个应用通过JVM参数[-Dio.netty.tryReflectionSetAccessible=true]开启了这个特性，这也是大多数应用上面的行为）UNSAFE.allocateMemory分配内存，完全绕过Java的直接内存API。然后它自己实现了内存占用空间的限制，这个值等于JVM参数中的MaxDirectMemorySize。到这里，似乎发现了曙光，莫非就是netty？（netty这么做的原因是为了不依赖JVM机制而加速内存的释放，同时也是为了解决在堆外内存不足时JVM的糟糕的回收机制设计。）

1.4.Netty到底占用了多少内存

好在netty的类中有一个静态变量是可以很容易的看到这个信息的：

io.netty.buffer.PooledByteBufAllocator#DEFAULT。

那么这个时候就是需要上机器去执行它了。Arthas是个不错的工具，可以直接在机器执行表达式看任何静态变量的值，并不需要我们改代码然后去调用上面的对象做日志打印。

登录机器后，通过命令查找netty Allocator的类定义：

sc -d io.netty.buffer.PooledByteBufAllocator

发现有不止一个Allocator，来自于不同的ClassLoader，以及不同的jar包。一共有7个。

然后一个一个的看他们实际占用的大小：

getstatic -c d5bc00 io.netty.buffer.PooledByteBufAllocator DEFAULT

然后把他们占用的内存逐项加起来，发现的确超过了1G，同时和前面通过NMT看到的Other类别的内存大小是比较吻合的。到这里大概就明确具体是怎么回事了，内存是netty用掉的。

1.5.业务应该怎么做呢

到目前为此，问题是明确了，但似乎并没有什么太好的解法。一个是rocketmq-client的内存占用是不是太大了，有没有什么可以优化的地方？（从前面看native内存看到的内容来看，还是有很大的优化空间的，一大堆地址信息都是以字符串的形式写在内存里面），另一个是中间件的调整肯定是长期的，短期业务要怎么办呢？

思考再三，短期来看只能是先让业务把Java堆调小（通过Java dump以及JVM监控可以看出来堆的使用率并不高），来适应当前的现状了。

至于堆外内存大小没有限制住的问题，我感觉并不是中间件同学的预期之中的，这块后面也找相关同学聊一聊。

后记

以后排查Java堆外内存过大的问题，优先看netty的占用。