java中的mmap实现

• 什么是mmap
    mmap对于c程序员很熟悉，对于java程序员有点陌生。简而言之，将文件直接映射到用户态的内存地址，这样对文件的操作不再是write/read,而是直接对内存地址的操作。
    在c中提供了三个函数来实现
    [list]
   
• mmap 进行映射
   
• munmap 取消映射
   
• msync 进程在映射空间的对共享内容的改变并不直接写回到磁盘文件中，往往在调用munmap()后才执行该操作。  
   

    具体参照http://blog.chinaunix.net/uid-24517893-id-164217.html

java中的map

    java中的FileChannel，提供了map和force方法，map创建文件和内存的映射，
  

 MappedByteBuffer buffer = fc.map(MapMode.READ_WRITE, 0, 1000);

    返回一个MappedByteBuffer，这是一个DirectBuffer，其中包含一个内存地址，然后可用就做一些读写操作。
    还有另外一个方法是force，是将内存的更新的内容刷到磁盘中。
    在这里抛出一个问题，force是必须调用的，如果不调用force会怎样。
    我试着写了一段小程序来试验
   

     MappedByteBuffer buffer = fc.map(MapMode.READ_WRITE, 0, 1000);
            for (int i = 0;i< 100000;i++){
                buffer.put((byte)65);
            }
      System.out.println("write completed!");
            System.in.read();
    

    然后观察文件发现文件中是有1000个B的，那么就是说不调用force，内容也会落到磁盘中的。既然不用force内容也可以落到磁盘中，那force的作用什么呢？带着这个问题我查看了openJdk的force和map的实现和linux中mmap的实现。

JDK的force和map的实现

  通过FileChannel->FileChannelImpl的native知道，对linux平台调用应该在D:\git\openjdk\jdk\src\solaris\native\sun\nio\ch下的FileChannelImpl.c

NIEXPORT jlong JNICALL
Java_sun_nio_ch_FileChannelImpl_map0(JNIEnv *env, jobject this,
                                     jint prot, jlong off, jlong len)
 mapAddress = mmap64(
        0,                    /* Let OS decide location */
        len,                  /* Number of bytes to map */
        protections,          /* File permissions */
        flags,                /* Changes are shared */
        fd,                   /* File descriptor of mapped file */
        off);                 /* Offset into file */

JNIEXPORT jint JNICALL
Java_sun_nio_ch_FileChannelImpl_force0(JNIEnv *env, jobject this,
                                       jobject fdo, jboolean md)
{
    jint fd = fdval(env, fdo);
    int result = 0;

    if (md == JNI_FALSE) {
        result = fdatasync(fd);
    } else {
        result = fsync(fd);
    }
    return handle(env, result, "Force failed");
}

原来force是调用的fdatasync(fsync)，这不是linux中buffered IO，write(2)以后需要调用的方法吗，难道mmap也是走的BufferdIO那一套，首先写到page cache，然后由pdflush定时刷到磁盘中，那这么说mmap只是在进程空间分配一个内存地址，真实的内存还是使用的pagecache。所以force是调用fsync将dirty page刷到磁盘中，但mmap还有共享之类的实现起来应该很复杂。

验证

  为了验证上面的假设，我做了一个实验。在linux下起两个终端，A终端通过上面的程序向a.txt写入数据，B终端使用tailf a.txt观察数据的写入。奇怪的是A终端执行完，B终端立马就成看到数据，而不是等30s以后pdflush刷到磁盘以后才能看到，难道前面的假设错了？或者另一种可能tailf查看到也是在page cache中读取的。那只需查看下文件的page是不是dirty就知道了。

cat /proc/$(pidof java)/smaps|grep a.txt -A 10 -B 10

就可以查看一个文件的page是否是dirty。
重新实现使用如上脚本观察

2aaab30c4000-2aaab31b9000 rw-s 00000000 fd:00 81887299                   /opt/zhanghailei/a.txt
Size:               980 kB
Rss:                980 kB
Shared_Clean:         0 kB
Shared_Dirty:         0 kB
Private_Clean:        0 kB
Private_Dirty:      980 kB
Swap:                 0 kB
Pss:                980 kB

果然是dirty的，然后继续等待一段时间再次执行发现已经是clean，被刷到磁盘中。

2aaab30c4000-2aaab31b9000 rw-s 00000000 fd:00 81887299                   /opt/zhanghailei/a.txt
Size:               980 kB
Rss:                980 kB
Shared_Clean:         0 kB
Shared_Dirty:         0 kB
Private_Clean:      980 kB
Private_Dirty:        0 kB
Swap:                 0 kB
Pss:                980 kB

结论

1. mmap，底层还是走的BufferedIO，好处大概是减少了内核态和用户态的内存拷贝，这点不太确定，对内核不熟。
2. force，参数为true调用fsync，false调用fdatasync，fdatasync只刷数据不刷meta数据
3. 即使不调用force，内核也会定期将dirty page刷到磁盘，默认是30s。

评论

2 楼 xiaoZ5919 2014-07-18  

cs6641468 写道

JAVA里处理文件应该慎用内存映射。
据说在FileChannel.map时，MappedByteBuffer已经在系统内占用了一个句柄，但使用FileChannel.close时无法释放掉。通用的一个work round方法是利用反射来clean掉这个引用，但是需要JDK1.7

我看JDK1.7的实现，你提到的这个问题，其实不存在的。如果需要我们显式地执行cleaner的clean的话，那么jdk肯定就public这个方法了，而不是用反射的方式。MappedByteBuffer会在占用一段内存地址空间，当close的时候并不会释放，只有进程结束或者调用了munmap以后才会释放。在MappedByteBuffer的实现中，添加了cleaner这是一个虚引用，当gc以后处理虚引用的时候会调用munmap 所以不需要关心或者用反射的方式显式调用

1 楼 cs6641468 2014-07-17  

JAVA里处理文件应该慎用内存映射。
据说在FileChannel.map时，MappedByteBuffer已经在系统内占用了一个句柄，但使用FileChannel.close时无法释放掉。通用的一个work round方法是利用反射来clean掉这个引用，但是需要JDK1.7