欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

java中的mmap实现 linuxjava 

程序员文章站 2022-05-06 13:00:30
...
  • 什么是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。

    相关标签: linux java