mmap java_Java文件映射[Mmap]揭秘 | 学步园

Java文件映射[mmap]揭秘

前言

相信现在做Java的人没有人不用NIO来进行IO相关的操作了吧。这个新的IO类库[虽然现在已经不新了]为我们带来了基于块的IO处理方式，通过预定义的Buffer，我们可以更高效地完成IO操作。在NIO中，我比较关注的是一个成为mmap的文件映射功能，其特点是可以把文件的一部分或全部映射到内存中，之后我们就可以通过MappedBuffer对内存进行操作，而操作的结果会由操作系统负责flush到文件中。由于应用程序只是操作内存，所以处理速度比普通的文件操作快很多，在某些应用场景下mmap可以发挥相当大的作用。本文就来揭秘java的mmap背后的工作原理和实现方法，以及使用java的mmap要注意的一些问题。

1功能简析

作为NIO的一个重要的功能，Mmap方法为我们提供了将文件的部分或全部映射到内存地址空间的能力，同当这块内存区域被写入数据之后[dirty]，操作系统会用一定的[这一过程java并没有提供API，后面会提到]。这样我们实际上就获得了间接操纵内存的能力，而且内存与文件之间的同步是由操作系统完成的，不用我们额外操心。也就是说，只要我们把内存数据块规划好[也就是实现一下C语言的SharedMemory功能]，剩下的事情交给操作系统烦恼就好了。我们既获得了高效的读写操作能力，又解决了数据的持久化问题，多么理想的功能啊！但必须说明的是mmap毕竟不是数据库，不能很方便地提供事务功能、类似sql语句那样的查找功能，也不具备备份、回滚、迁移的能力，这些都要自己实现。不过这样显然不如放在数据库里放心，所以我们的经验是特别重要的数据还是存数据库，不太重要的、但是又访问量很大、读写操作多且需要持久化功能的数据是最适合使用mmap功能的。使用Java的mmapAPI代码框架如下所示：

(1)RandomAccessFile raf = new RandomAccessFile (File, "rw");

(2)FileChannel channel = raf.getChannel();

(3)MappedByteBuffer buff = channel.map(FileChannel.MapMode.READ_WRITE,startAddr,SIZE);

(4)buf.put((byte)255);

(5)buf.write(byte[] data)

其中最重要的就是那个buff，它是文件在内存中映射的标的物，通过对buff的read/write我们就可以间接实现对于文件的读写操作，当然写操作是操作系统帮忙完成的。

虽然mmap功能是如此的强大，但凡事都有局限，java的mmap瓶颈在哪里？使用mmap会遇到哪些问题和限制？要回到这些问题，还是需要先从mmap的实现入手。

2实现原理

研究实现原理的最好方式就是阅读源码，由于SUN(或许不应该这样叫了？)开放了JDK源码，为我们的研究敞开了大门，这里我采用的是linux版的JDK1.6_u13的源码。

2.1目标和方法

在查看Java源码之前，我首先google了一下mmap，结果发现mmap在linux下是一个系统调用：

void *mmap(void *addr, size_t len, int prot, int flag, int filedes, off_t off );

man了一下发现其功能描述和JavaAPI上说的差不多，难道JDK底层就是用这个东东实现的？马上动手写个程序然后STrace一下看看是不是使用了这个系统调用。这个测试程序应用的就是上面提到的那个程序框架，map了1G的文件，然后每次一个字节地往里面写数据，由于很简单这里就不贴出来了。结果如下：

为简便起见中间的内容就忽略掉了，不过我们可以很清楚地看到mmap的操作就是打开[使用open系统调用]文件，然后mmap之，之后的操作都是对内存地址的直接操作，而操作系统负责把剩下的事情搞定了。于是可以大胆预言，java的实现是用JNI包装了的mmap()系统调用。其功能也应该和下图所示的内容保持一致。

《APUE》中关于Mmap()系统调用的示意图

在经过上面的分析之后，我们已经有了初步的目标，那就是找到JavaMmap的C源码，看其使用了哪些系统调用。这样我们就可以更好地了解和控制JavaMmap的行为。

2.2询源之旅

还是以上面这个代码框架为例，注意这里除了map文件的动作之外就只有写操作，因为mmap的读方法是读内存的，我们已经很清楚，所以这里我们只关心写操作。通过阅读源码，我得到的结论如下：

(1)打开文件和建立FileChannel这两步应该只有一个open()系统调用。

(2)mmap方法没什么悬念地用到了mmap系统调用。但值得注意的是JDK只提供了建立文件/内存映射的方法，而没有给出解除映射关系的API。在FileChannelImpl.java中我们可以看到，解除映射的方法[在Unmapper中定义]是在创建MappedByteBuffer时嵌入到这个类里面的，在buffer被GC回收之前会调用Unmapper的unmap方法来解除文件到内存的映射关系。也就是说我们要想解除映射只能先把buffer置为null，然后祈祷GC赶紧起作用，实在等不及还可以用System.gc()催促一下GC赶快干活，不过后果是会引发FullGC。

(3)对于map到内存中的部分的写操作就是对内存地址的写操作，只不过jdk用的是jni。

3 诡异的问题

因为在一般运维监控的时候，我们都会很自然地选择Top或者PS看一下进程当前实用的物理内存是多少，以防进程内存占用过高导致系统崩溃。虽然TOP/PS的结果不是十分精确，但是大部分时候还是够用的。然而在使用了java的mmap之后我们发现，top