java.lang.OutOfMemoryError: Map failed

最近遇到这个Exception,发现不少开源框架在实现快速读写文件时,采用的都是FileChannel的map方法,示例如下:

at sun.nio.ch.FileChannelImpl.map0(Native Method) ~[?:1.8.0_40]
at sun.nio.ch.FileChannelImpl.map(FileChannelImpl.java:904) ~[?:1.8.0_40]

这个方法的作用是将文件映射到堆外内存中,然后通过读写内存来实现对文件的快速读写。从知乎摘了一张图。
mmap display


问题 & 解决

目前来看,我在使用MapDB和Phoenix时都曾经出现过这个Exception,MapDB直接将DB文件映射到堆外内存,来达到高效的读写;Phoenix在结果集过大时,需要落地成临时文件,而这个临时文件是采用mmap来操作的。

Map Failed 出现的原因有很多:

  1. 对于32-bit JVM,由于地址空间是32 bit,2^32=4GB,所以我们能映射的文件大小只有4GB,但实际上因为其他对象同样需要占用地址空间,所以正常情况下,只能映射1GB左右。
  2. Java程序有默认的maxDirectMemory,即JVM可使用的最大堆外内存,稍不注意,就有可能超过并且抛出异常(如在Phoenix数据查询中结果集过大)。
  3. mmap句柄超过了系统默认最大值。系统默认最大值可使用cat /proc/sys/vm/max_map_count查看,进程使用句柄数可使用cat /proc/$PID/maps | wc -l查看。每一块申请的ByteBuffer都对应一个mmap句柄,也就是说,如果生成了大量的碎ByteBuffer,那么句柄数也会急剧增长。而这些句柄的回收是伴随着ByteBuffer回收的,堆外内存的GC需要显示调用System.gc来进行。

解决方式:

  1. 若为32-bit JVM,可升级到64-bit,获得更大的地址空间。
  2. 若为64-bit JVM,当超出堆外内存不多且使用总内存小于32GB时,使用-XX:useCompressedOops来压缩对象的空间大小。
  3. 调整-XX:maxDirectMemorySize来获得更多的堆外内存。
  4. 调整/proc/sys/vm/max_map_count。