本文记录一次堆外内存OOM的排查过程。
周末的时候共事对线上服务进行了一次扩容，本认为只是简略减少几个实例而已，后果新实例接入流量后疯狂报警，只能马上切换下线，查看日志后发现如下谬误：

jstat命令查看GC信息发现fullgc十分多

因为线上服务部署在k8s集群中，实例是运行在docker环境的，镜像没有任何批改，而这个镜像曾经上线将近一个月了，为什么曾经上线的服务没有问题而新退出的实例疯狂报警，带着一头雾水回顾了下之前排查线上性能问题的各种伎俩，貌似都对堆外内存问题排查大刀阔斧，周末始终思考这个问题也进行了一些尝试，无果。
转瞬周一到了，到公司后第一工夫查看了相干的一些参数，看了曾经在线上的服务，吓了一跳，线上服务堆外内存也靠近爆满(6G下限)，惟恐线上服务全副挂掉。
静下心来想了下咱们服务中哪些模块应用了堆外内存，第一个想到的是咱们的RPC框架，因为底层应用了netty会应用堆外内存，为了验证这个问题我也查看了另外一组十分相近的上游服务，后果发现这个服务的堆外内存使用量十分小，只有20M左右，排除掉RPC组件的问题。
为了看一下堆外内存的增长曲线，我将线上服务又扩了一个正本，后果发现一个重要的线索，实例启动胜利后堆外内存根本就曾经靠近下限了。那么就省去流量模仿了，于是我在本地启动了一个服务，查看内存应用状况，后果发现启动阶段堆外内存暴涨，到肯定水平后开始稳固，于是应用排除法，将狐疑有问题的组件正文掉，很快定位到了公司的一个存储服务jar包上，又本地进行了一次内存dump，因为这个jar包没有应用netty那么它必定应用了DirectByteBuffer，于是在VisualVM中对dump进行了剖析，发现DirectByteBuffer的持有者集中在了存储服务客户端的连贯对象NioChannel上，下一步对这个链接对象进行了反编译，搜寻了一下ByteBuffer#allocateDirect办法很快发现了一个问题，这个对象初始化的时候申请了4M的堆外内存，也就是说每个链接初始化的时候要申请4M的堆外内存，于是对咱们线上的服务执行了jmap -histo查看对象数统计，发现线上服务NioChannel对象多达1451个，如下图

大略算了下，每个对象持有4M堆外内存，这1451个对象要5804M将近6G的堆外内存，问题一下子清朗了起来，能够判定线上的堆外内存就是这里的问题，顺着代码找过来原来这个链接的buffer是能够设置的，分割了存储的同学，对方示意这个buffer能够设置小一点，影响不大。为什么只有咱们遇到了这个问题呢，原来是因为咱们的连接数比拟多的缘故，而这个链接数过多的问题其实是咱们的业务起因造成的，并没有改良空间，于是这个问题目前的解决办法也只有调小buffer。

至此堆外内存使用量过高的问题解决了，那么fullgc过多的问题是怎么回事呢，线上的gc日志是关上的，拉下来一份看了下，如下图所示：

能够看到一个比拟显著的问题，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。