最近遇到这个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]
这个方法的作用是将文件映射到堆外内存中,然后通过读写内存来实现对文件的快速读写。从知乎摘了一张图。
问题 & 解决
目前来看,我在使用MapDB和Phoenix时都曾经出现过这个Exception,MapDB直接将DB文件映射到堆外内存,来达到高效的读写;Phoenix在结果集过大时,需要落地成临时文件,而这个临时文件是采用mmap来操作的。
Map Failed 出现的原因有很多:
- 对于32-bit JVM,由于地址空间是32 bit,2^32=4GB,所以我们能映射的文件大小只有4GB,但实际上因为其他对象同样需要占用地址空间,所以正常情况下,只能映射1GB左右。
- Java程序有默认的maxDirectMemory,即JVM可使用的最大堆外内存,稍不注意,就有可能超过并且抛出异常(如在Phoenix数据查询中结果集过大)。
- mmap句柄超过了系统默认最大值。系统默认最大值可使用
cat /proc/sys/vm/max_map_count
查看,进程使用句柄数可使用cat /proc/$PID/maps | wc -l
查看。每一块申请的ByteBuffer都对应一个mmap句柄,也就是说,如果生成了大量的碎ByteBuffer,那么句柄数也会急剧增长。而这些句柄的回收是伴随着ByteBuffer回收的,堆外内存的GC需要显示调用System.gc来进行。
解决方式:
- 若为32-bit JVM,可升级到64-bit,获得更大的地址空间。
- 若为64-bit JVM,当超出堆外内存不多且使用总内存小于32GB时,使用-XX:useCompressedOops来压缩对象的空间大小。
- 调整-XX:maxDirectMemorySize来获得更多的堆外内存。
- 调整/proc/sys/vm/max_map_count。