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和ps命令居然失效了。在我们的程序中map了一个3G大小的文件[这个文件自此之后一直没有变大]，可是过几天之后[当然程序里面还有一些业务逻辑]却发现TOP命令的RSS字段居然变成了19G，更夸张的是过几天之后RSS的值仍然在不断增长，这已经远远超过了内存的实际大小，但此时系统的IO并不高，效率没有降低，也根本没用到swap。这就是说TOP/PS的结果是有问题的，此时的RSS已经不能正确标示当前进程所占用的物理内存了，而导致这个问题发生的原因又是什么呢？

为此我查看了一下/proc/PID/smaps文件，因为这里面描述了进程地址空间的使用情况，我得到的结果是：

同一个文件被map了几次，smap文件中就有多少条记录项。于是我们可以大胆猜想，TOP/PS命令是否就是把smaps文件的中RSS做了一个简单的加法输出出来？后来经我们验证果然是这样的！也就是说文件被统一进程map的次数越多，smaps里面的对应项也就越多，所以TOP/PS的RSS字段值也就越大。

既然TOP/PS的值已经不可靠了，那么应该怎样获取使用了mmap的进程当前所占用的物理内存呢？google了一下排名最靠前的是一个叫做exmap的工具，不过那个工具不仅自己要重新编译，还需要重新编译内核[因为可能操作系统禁用了Module载入]，最不能接受的是还是图形界面的，还有可能造成性能上的不稳定，这些限制使其在开发机上部署和使用变得不现实。后来用尝试了一些系统调用和shell命令，效果都不太理想。

4       后记

我们略带遗憾地结束了Java的Mmap之旅，最终也没能找到一个简单而准确的方法来查看当前进程的占用了多少物理内存[前提是不引入影响系统性能的组件和不引入带界面的东西]，如果哪位有更好的办法[无论是应用那个命令或者写个小程序都可以]请通过email联系我jxuedi@gmail.com，您的方法如果证明确实有效我会送您一个45cm的QQ公仔聊表谢意，同时也可以为这篇文章画上一个完满的句号，期待中……