Native函数库导致OOM的触发原理

线上应用经常会出现OutOfMemoryError错误，档案引起原因多种多样，包括堆内存溢出（Java Heap Space）、方法区持久代内存溢出（Permanet Space）以及本文需要说道的Native操作本地内存出现的内存溢出问题。要说明这个问题，就先要说明Native函数库是怎样操作内存空间的。

NIO中的Native函数库

在JDK1.4中新加入了NIO类，引入一种基于渠道与缓冲区的I/O方式，它可以通过本机Native函数库直接分配本机内存，然后通过一个存储在Java堆里面的DirectByteBuffer对象作为这块内存的引用进行操作。所以由Native函数库引起的OOM大多是由于直接使用了本地直接内存（Direct Memory）。

NIO之所以引入该机制，这样能在一些场景中显著提高性能，因为避免了在Java对和本机堆中来回复制数据。显然本机直接内存的分配不会受到Java堆大小的限制，但是即然是内存那肯定还是要受到本机物理内存（包括SWAP区或者Windows虚拟内存）的限制的，一般服务器管理员配置JVM参数时，会根据实际内存设置-Xmx等参数信息，但经常忽略掉直接内存，使得各个内存区域总和大于物理内存限制（包括物理的和操作系统级的限制），而导致动态扩展时出现OutOfMemoryError异常。

关于如何定位OOM异常，请参看我的另一篇文章《一次线上OOM排查经过》。

设定JVM参数

按照jvm规范，本地直接内存的最大值按以下顺序设定：

1. 通过-XX:MaxDirectMemorySize=<size>指定值
2. 若（1）未满足，则就取maxMemory，也就是通过-Xmx设定的值；
3. 若（1）、（2）都未满足，则取默认值：64M；

根据以上知识，结合此次测试情况，问题基本水落石出：

假设在我们测试日常机中，系统启动的时候设定-Xmx 3072m，没有通过-XX:MaxDirectMemorySize设定本地直接内存最大值，因此本地直接内存最大值就是-Xmx设定的值3072m，整个系统的物理内存为4G，除掉系统进程占用的内存，剩下的物理内存加上swap空间也就接近3G。设想JVM的heap size占用了1.5G，direct memory使用了1.5G，这时候程序申请一100M的direct内存，在这种情况下无论是JVM heap size还是direct memory不满足触发gc的条件，于是jvm向os申请分配内存，但是OS却无可分配的内存了，于是就会抛出OutOfMemoryError错误。

因此，在使用NIO框架时的时候一定要注意：如果该NIO框架使用的直存，需谨慎设定JVM运行参数，最好用-XX:MaxDirectMemorySize进行设定，否则你就得清楚你设定的-Xmx不单单制定了heap size的最大值，它同时也是direct memory的最大值。

NIO与OOM

一、首先对于可用内存这一概念的理解

在32位机器上，CPU可寻址的物理内存空间最大是4G，超出4G将不再可见。【此处忽略PAE支持，如果进程中使用了AWE(windows)或者mmap(linux)一类的方案，这里暂时不管了】

这4G的物理内存空间又分为用户空间和内核空间。默认情况下，windows按照50:50的比例划分，linux默认下用户空间3G，内核空间1G。

所以一个进程可用的物理内存空间，在linux32位机器下，就是3G。而在64位机器下，基本上可以认为是没有任何限制，原理很简单了。。。

不管是linux还是windows，可用内存空间由：物理内存+swap/虚拟内存组成。Linux上称作swap【交换空间】，windows上称作虚拟内存，本质上都是拿磁盘的一块地方当作物理内存使用。程序是不用关心使用的是物理内存，还是swap；程序操作的是虚拟地址空间， OS再将虚拟地址空间映射到物理内存、文件或者其他。不管是操作物理内存，还是swap，对于程序来说完全是透明的。

Swap/虚拟内存啥时候会使用，这个我也没完全搞清楚，不过有一点应该没错的，就是进程新申请的内存，不会在swap/虚拟内存中分配，而是直接在物理内存中分配。当内存紧张时，OS会将活动进程中占用的内存，从物理内存中交换出来，放到Swap/虚拟内存上（有时甚至内存不紧张也会这么干）。当进程恢复活动时，OS再将数据从swap/虚拟内存空间中读出来放到物理内存中

所以当需要分析和计算进程需要占用的内存空间时，可以简单地忽略swap/虚拟内存的概念【这一点需要深入再论证一下！】

二、JVM对内存的管理

JVM内存空间主要分成三部分：

1.  堆空间

包括年轻化、年老代、持久域【以SUN HOTSPOT虚拟机实现为例，其他虚拟机会有区别，比如IBM的虚拟机，所谓的“持久域”不是在堆分配，而是在本地内存】

如果这个空间不够了，会抛出java.lang.OutOfMemoryError

2.  栈空间

每个线程都会有一个单独的stack空间，JDK5.0以前默认好象是256K，JDK5.0默认是1M，很大的一个数值，可以通过-Xss设置。如果这个空间不够了，会抛出java.lang.StackOverflowError

3.  本地内存

Jvm进程可使用的内存,除去堆、栈空间之后，剩下来的就是本地内存

以上三个空间加起来的内存，就是最终jvm进程所使用的所有内存。如果是在32位机器下，不能超过用户空间大小，即3G；在64位机器下，就要看物理内存的大小了

另再提醒一下大家，在发生了内存不足时，一味地增加-Xms和-Xmx，很有可能会适得其反，道理应该很明显了。需要看OOM的类型，是堆不足，还是栈(StackOverFlow)不足，还是本地内存不足native memory。jvm一般都会有足够的信息提示的。

三、Nio的direct memory allocate

我理解的，NIO的直接内存分配【DMA】，应该是从本地内存区域中分配内存。像前面讲的，如果不使用-XX:MaxDirectMemorySize设置，那它就会使用-Xms的设置，以日常测试环境为例， 这种情况下DMA需要3G，堆也需要3G,很明显实际上这两个空间得到的内存都不可能这么大，所以要么是堆空间被挤压，拿不到3G，要么是DMA拿不到足够的空间

看jvm抛出来的错误，应该是堆空间被挤压导致的。如果是本地内存不足，抛出的应该是OutOfMemoryError :Direct buffermemory，可以看一下java.nio.DirectByteBuffer这个类的源码，98行

四、NIO2.0的改进

NIO的DMA，性能肯定比在堆中分配要好得多，因为是直接操作本地内存，避免了数据在JVMHeap和本地内存之间的拷贝操作，尤其是数据量较大时应该更加明显。

 

更多关于JAVA架构知识分享，欢迎访问《架构师之路》。