关于JVM的直接内存

最近，同事定位到一个直接内存溢出的问题，即直接内存不足导致OOM。在此记录下关于直接内存的知识。

一、什么是直接内存

有的地方也叫堆外内存。这部分内存不归JVM管理。JDK8 开始后的JVM内存，可简单分为四大部分：

1. 程序计数器；

2. 栈，包括虚拟机栈和本地方法栈；

3. 堆；

4. 直接内存（堆外内存）

假设你申请的docker有8G，划了2G给堆，1G给栈，程序计数器的可以忽略不计，那堆外内存就大约是5G。

 

二、直接内存的好外

为什么要把内存分配到直接内存？跟分配在堆有什么区别 ？

在Java中，要远程发送一个对象的信息，需要先将对象从堆中移到直接内存，再进行传输。如果对象本身就分配在堆外，那就少了从堆内拷贝到堆外这一过程。从而使IO更加高效。

我们使用NIO 中的类 DirectByteBuffer，就可以分配到一块堆外内存 

三、堆外内存的回收

参考占小狼大神的博客 ：https://www.jianshu.com/p/35cf0f348275

可以简单地这么认为：

ByteBuffer buf = new ByteBuffer.allocateDirect(1024); 

这段代码会在堆外分配1024字节的内存，即对象引用是在堆内，但实际的内存是在堆外。当buf这个引用在程序中没有地方用到时，该引用会被回收。当该直接内存无任何引用时，在full gc中就会被回收。

可以通过 -XX:MaxDirectMemorySize 参数来设置最大可用直接内存，如果启动时未设置则默认为最大堆内存大小，即与 -Xmx 相同。

超过最大直接内存，则系统会调用System.gc()强制进行FGC。

细心的朋友可能注意到，JVM还有一个参数：-XX:+DisableExplicitGC，当应用这个参数时，System.gc()会变成一个空调用，JVM不会因为此方法的调用而去FGC。

这对严重依赖直接内存的系统可能会有点问题。这意味着只能靠系统的自发的FGC去回收直接内存，稍不注意，就有可能发生直接内存的OOM。

 

四、直接内存OOM排查

目前像Nettyy等IO框架，都会大量使用NIO；而很多RPC框架都会使用Netty。所以直接内存的OOM在分布式系统中可能会比较常见。

遇到了，可以从以下几个方面考虑：

1. 是否考虑去掉-XX:+DisableExplicitGC参数，使得System.gc()有可能进行FGC；

2. 堆内存不是越大越好。堆内存过大，会导致直接内存变小，而且堆太大，则会比较少触发 FGC，而只有FGC才有可能回收直接内存。可以考虑把堆设置得小一点。

这些调整建议仅供参考，需要结合实际项目来。