本文记录一次堆外内存OOM的排查过程。
周末的时候同事对线上服务进行了一次扩容，本以为只是简单增加几个实例而已，结果新实例接入流量后疯狂报警，只能马上切换下线，查看日志后发现如下错误：
image.png
jstat命令查看GC信息发现fullgc非常多
image.png
因为线上服务部署在k8s集群中，实例是运行在docker环境的，镜像没有任何修改，而这个镜像已经上线将近一个月了，为什么已经上线的服务没有问题而新加入的实例疯狂报警，带着一头雾水回忆了下之前排查线上性能问题的各种手段，貌似都对堆外内存问题排查束手无策，周末一直思考这个问题也进行了一些尝试，无果。
转眼周一到了，到公司后第一时间查看了相关的一些参数，看了已经在线上的服务，吓了一跳，线上服务堆外内存也接近爆满(6G上限)，生怕线上服务全部挂掉。
静下心来想了下我们服务中哪些模块使用了堆外内存，第一个想到的是我们的RPC框架，因为底层使用了netty会使用堆外内存，为了验证这个问题我也查看了另外一组非常相近的下游服务，结果发现这个服务的堆外内存使用量非常小，只有20M左右，排除掉RPC组件的问题。
为了看一下堆外内存的增长曲线，我将线上服务又扩了一个副本，结果发现一个重要的线索，实例启动成功后堆外内存基本就已经接近上限了。那么就省去流量模拟了，于是我在本地启动了一个服务，查看内存使用情况，结果发现启动阶段堆外内存暴涨，到一定程度后开始稳定，于是使用排除法，将怀疑有问题的组件注释掉，很快定位到了公司的一个存储服务jar包上，又本地进行了一次内存dump，因为这个jar包没有使用netty那么它肯定使用了
DirectByteBuffer，于是在VisualVM中对dump进行了分析，发现DirectByteBuffer的持有者集中在了存储服务客户端的连接对象NioChannel上，下一步对这个链接对象进行了反编译，搜索了一下ByteBuffer#allocateDirect方法很快发现了一个问题，这个对象初始化的时候申请了4M的堆外内存，也就是说每个链接初始化的时候要申请4M的堆外内存，于是对我们线上的服务执行了jmap -histo查看对象数统计，发现线上服务NioChannel对象多达1451个，如下图
image.png
大概算了下，每个对象持有4M堆外内存，这1451个对象要5804M将近6G的堆外内存，问题一下子明朗了起来，可以断定线上的堆外内存就是这里的问题，顺着代码找过去原来这个链接的buffer是可以设置的，联系了存储的同学，对方表示这个buffer可以设置小一点，影响不大。为什么只有我们遇到了这个问题呢，原来是因为我们的连接数比较多的缘故，而这个链接数过多的问题其实是我们的业务原因造成的，并没有改进空间，于是这个问题目前的解决办法也只有调小buffer。
至此堆外内存使用量过高的问题解决了，那么fullgc过多的问题是怎么回事呢，线上的gc日志是打开的，拉下来一份看了下，如下图所示：
image.png
可以看到一个比较明显的问题，fgc之前其实老年代远远没有达到fgc的阈值，触发fgc的原因是有代码调用了
System.gc()，而我们并没有刻意设置-XX:+DisableExplicitGC，也不想设置这个参数。那么接下来需要排查哪里进行了System.gc()调用。在网上查阅资料时偶然发现了一个线索这里：初始化DirectByteBuffer对象时，在一定条件下会主动调用
System.gc()。
查看了jdk的源码发现ByteBuffer#allocateDirect的过程中确实有一个System.gc()的调用，对比上边图1的调用栈可以确定是这里触发的fgc，也就是说fgc的问题其实是堆外内存OOM的副产品，堆外内存OOM的问题解决这个问题也会迎刃而解，至此问题原因排查清楚了。
那么为什么老实例和新实例会表现不一样呢，线上的实例并没有出现OOM的错误日志呢，问题的关键在于存储服务的client初始化后便不再变动，新实例初始化时比旧实例的连接数多，恰好到达了6G堆外内存上限附近，而netty的堆外内存是动态申请的，初始化时机比前者晚，请求进来时再申请堆外内存时没有可用的堆外内存了，触发了fgc，最终抛出了OOM。
