Memory-Mapped Files(MMAP)的深入探讨

关于Memory-Mapped文件的问题,问题多集中在在于unmap。官方有个05年至今还是Open状态的bug(参考1),说的就是unmap方法,其中有个回复说在JDK10中会解决,所有非常期待JDK10。 对于mmap的使用至今没有找到一个来源可靠的资料,能给个大概的使用。 网上对于java的MMAP文件使用资料不多,而且有大量今天看来是错误使用的。官方的API中对于mmap文件的使用,并未提供任何的unmap方法。对此给出的解释(参考1)和猜测的是一样的,还没有办法给出一个安全高效的unmap方法。

JVM在做垃圾回收的时候,实际上会对一个mmap的对象进行释放,相关实验代码参照 Java 文件读写相关,以及MappedByteBuffer的注释。 基于以上说明,和官方bug系统的回复。能够大概得出一个正确的使用。 mmap文件的使用,在当前情况下不用释放,像正常对象一样使用,gc会管理释放。 不能多次map同一文件。 一个文件被map到内存后会占用到用户空间,此时并没有做实际的文件载入,当访问到该内存时候会进行缺页处理载,将相应的页数据入物理内存。所以对于用户空间有限制的系统,会导致文件map 失败,而报内存不足的异常。

MMAP过程分析 Java中的Memory-Mapped文件最终还是到系统的内存映射上。 内存映射的实现过程,总的来说可以分为三个阶段:(这里简化了很多细节,详细的见参考2) (一)进程启动映射过程,并在虚拟地址空间中为映射创建虚拟映射区域 1、进程在用户空间调用库函数mmap 2、在当前进程的虚拟地址空间中,寻找一段空闲的满足要求的连续的虚拟地址(这个地方如果系统做了空间大小限制,同时gc后仍然没有足够空间,会抛内存不足的异常) 3、为此虚拟区分配一个结构,接着对这个结构的各个域进行了初始化 4、将新建的虚拟区结构插入进程的虚拟地址区域链表或树中

(二)调用内核空间的系统调用函数mmap(不同于用户空间函数),实现文件物理地址和进程虚拟地址的一一映射关系 5、为映射分配了新的虚拟地址区域后,通过待映射的文件指针,链接到内核“已打开文件集”中该文件的文件结构体。 6、通过该文件的文件结构体,调用内核函数mmap。 7、内核mmap函数通过虚拟文件系统定位到文件磁盘物理地址。 8、通过remap_pfn_range函数建立页表,即实现了文件地址和虚拟地址区域的映射关系。此时,这片虚拟地址并没有任何数据关联到主存中。

(三)进程发起对这片映射空间的访问,引发缺页异常,实现文件内容到物理内存(主存)的拷贝 注:前两个阶段仅在于创建虚拟区间并完成地址映射,但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。 9、进程的读或写操作访问虚拟地址空间这一段映射地址,通过查询页表,发现这一段地址并不在物理页面上。因为目前只建立了地址映射,真正的硬盘数据还没有拷贝到内存中,因此引发缺页异常。 10、缺页异常进行一系列判断,确定无非法操作后,内核发起请求调页过程。 11、调页过程先在交换缓存空间(swap cache)中寻找需要访问的内存页,如果没有则调用nopage函数把所缺的页从磁盘装入到主存中。 12、之后进程即可对这片主存进行读或者写的操作,如果写操作改变了其内容,一定时间后系统会自动回写脏页面到对应磁盘地址,也即完成了写入到文件的过程。

Java 中使用 MMAP

正如参考1中提到的,没有一个可靠的技术来确保,安全地 unmap 一个文件映射。实际使用中 mmap 的方式的确有一定的风险。稍有不慎就会导致访问非法内存,从而导致 JVM 的崩溃。 这里提供一个较为准确的使用方案。

不理会方式

这个是应该是官方提倡的方式,毕竟不提供 unmap 方法,开发者只能不管不问了。使用起来只需要确保不再使用的对象没有引用即可。JVM 会在 gc 的时候去释放这块内存映射。 下面是FileChannelImpl#map()中的具体实现,在第一次抛OutOfMemoryError的时候,会将异常捕获,并且主动调用 gc 触发垃圾回收。

try {
    var7 = this.map0(var6, var13, var15);
} catch (`OutOfMemoryError` var30) {
    System.gc();

    try {
        Thread.sleep(100L);
    } catch (InterruptedException var29) {
        Thread.currentThread().interrupt();
    }

    try {
        var7 = this.map0(var6, var13, var15);
    } catch (OutOfMemoryError var28) {
        throw new IOException("Map failed", var28);
    }
}

主动释放

下面的代码可以直接使用

/**
   * Forces to unmap a direct buffer if this buffer is no longer used. After calling this method,
   * this direct buffer should be discarded. This is unsafe operation and currently a work-around to
   * avoid huge memory occupation caused by memory map.
   *
   * <p>
   * NOTE: DirectByteBuffers are not guaranteed to be garbage-collected immediately after their
   * references are released and may lead to OutOfMemoryError. This function helps by calling the
   * Cleaner method of a DirectByteBuffer explicitly. See <a
   * href="http://stackoverflow.com/questions/1854398/how-to-garbage-collect-a-direct-buffer-java"
   * >more discussion</a>.
   *
   * @param buffer the byte buffer to be unmapped, this must be a direct buffer
   */
  public static synchronized void cleanDirectBuffer(ByteBuffer buffer) {
    Preconditions.checkNotNull(buffer, "buffer");
    Preconditions.checkArgument(buffer.isDirect(), "buffer isn't a DirectByteBuffer");
    try {
      if (sByteBufferCleanerMethod == null) {
        sByteBufferCleanerMethod = buffer.getClass().getMethod("cleaner");
        sByteBufferCleanerMethod.setAccessible(true);
      }
      final Object cleaner = sByteBufferCleanerMethod.invoke(buffer);
      if (cleaner == null) {
        if (buffer.capacity() > 0) {
          LOG.warn("Failed to get cleaner for ByteBuffer: {}", buffer.getClass().getName());
        }
        // The cleaner could be null when the buffer is initialized as zero capacity.
        return;
      }
      if (sCleanerCleanMethod == null) {
        sCleanerCleanMethod = cleaner.getClass().getMethod("clean");
      }
      sCleanerCleanMethod.invoke(cleaner);
    } catch (Exception e) {
      LOG.warn("Failed to unmap direct ByteBuffer: {}, error message: {}",
                buffer.getClass().getName(), e.getMessage());
    } finally {
      // Force to drop reference to the buffer to clean
      buffer = null;
    }
  }

主动的方式需要注意的是,一定要在确保当前 DirectByteBuffer 是不再使用的,否则会引起 JVM 崩溃。

写在最后

文件的内存映射是非常快速的一种访问方式。而且在对于通过指定位置访问文件的方式,也有着非常棒的性能,因此它带来的速度的提升吸引着我们承担 JVM 崩溃的风险。所有为了避免JVM 崩溃,一地要牢记释放后的对象不能再次访问。

参考1:http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4724038 参考2:http://www.cnblogs.com/huxiao-tee/p/4660352.html 参考3:Linux设备驱动程序

最近的文章

分布式大表Join

在数据分布在不同机器的场景下,join 计算一直是一个难点,因为 join 涉及到大量数据传输。从已有的 join 算法来看,如何减少数据传输是加快 join 的核心。sort merge join,hash join和broadcast join是目前常用的 join 方法。这些算法适用于不同的场景,能很大程度上加快 join 的速度。但是对于列多的大表情况下,生成中间表并持久化就显得力不从心。场景描述需要对两张行和列都很多的表做 join ,并将 join 表持久化,生成一张中间表。下...…

继续阅读
更早的文章

Allxuio之UFS数据读取

Client读取UFS的数据首先在《Alluxio的FileInStream记录》一文中将Local模式的介绍了一遍。但是有个疑问:如果文件是写在UFS(底层文件存储)上的话,那么文件改如何读取呢?开始我以为会像Local模式一样,通过NIO的MappedByteBuffer读取UFS上的文件,并且同时cache到Mem中。再仔细看完代码后,发现事实并非如此,在FileInStream中,只要是非Local模式的,都会通过Netty走网络,即使是在本机的UFS上面也是如此。主要是Local...…

继续阅读