问题排查之OOM （非原创，来自于同事的邮件分享）

非原创，来自于同事的邮件分享。

前段时间在测试过程中发现了mina 框架的问题：当mina 一次传输的文件超过一定值（如55m ）或者连续传输文件的次数过于频繁，就会内存溢出：

org.apache.mina.filter.codec.ProtocolEncoderException: java.lang.OutOfMemoryError: Java heap space

at org.apache.mina.filter.codec.ProtocolCodecFilter.filterWrite(ProtocolCodecFilter.java:217)

at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:361)

at org.apache.mina.common.support.AbstractIoFilterChain.access$1300(AbstractIoFilterChain.java:53)

at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.filterWrite(AbstractIoFilterChain.java:659)

at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.filterWrite(AbstractIoFilterChain.java:587)

at org.apache.mina.common.support.AbstractIoFilterChain.callPreviousFilterWrite(AbstractIoFilterChain.java:361)

at org.apache.mina.common.support.AbstractIoFilterChain.fireFilterWrite(AbstractIoFilterChain.java:355)

at org.apache.mina.transport.socket.nio.SocketSessionImpl.write0(SocketSessionImpl.java:166)

at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:177)

at org.apache.mina.common.support.BaseIoSession.write(BaseIoSession.java:168)

at com.taobao.forest.server.DefaultPushTimeTask.pushcachetothesession(DefaultPushTimeTask.java:441)

1 ） 开始是尝试用常规方法试图分析mina 在内存溢出时什么东东占了那么多内存还无法释放，于是在jboss 启动参数那加了两个参数-XX:HeapDumpPath=\tmp  -XX:+HeapDumpOnOutOfMemoryError ， 作用是在发生OutOfMemoryError 时将当时的内存映像dump 到/tmp 下，然后将dump 出来的内存映像文件下到本地用mat 分析，不过分析结果未发现有内存溢出问题，甚是奇怪。

2 ）之后，又上网查了些资料，才发现mina 不是用的堆内存（Heap ），而是使用的本机直接内存（Direct Memory ）

所谓本地直接内存 并不是虚拟机运行时数据区的一部分，它根本就是本机内存 而不是VM 直接管理的区域。

在JDK1.4 中新加入了NIO 类，引入一种基于渠道与缓冲区的I/O 方式，它可以通过本机Native 函数库直接分配本机内存 ，然后通过一个存储在Java 堆里面的DirectByteBuffer 对象作为这块内存 的引用进行操作。这样能在一些场景中显著提高性能，因为避免了在Java 对和本机堆中来回复制数据。显然本机直接内存 的分配不会受到Java 堆大小的限制，但是即然是内存 那肯定还是要受到本机物理内存 （包括SWAP 区或者Windows 虚拟内存 ）的限制的，一般服务器管理员配置JVM 参数时，会根据实际内存 设置-Xmx 等参数信息，但经常忽略掉直接内存 ，使得各个内存 区域总和大于物理内存 限制（包括物理的和操作系统级的限制），而导致动态扩展时出现OutOfMemoryError异常 。

此外，按照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 buffer memory ，可以看一下java.nio. DirectByteBuffer 这个类的源码，98 行

四、 NIO2.0 的改进

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