本文记录一次堆外内存 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。