转（Java文件映射[mmap]揭秘）

转载自：http://blog.csdn.net/kabini/archive/2009/06/21/4286737.aspx

 

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联系我[e-mail] ，您的方法如果证明确实有效我会送您一个 45cm 的 QQ 公仔聊表谢意，同时也可以为这篇文章画上一个完满的句号，期待中 ……