为什么mmap后，比直接对文件read/write效率更高

- 日理万妓 2022-02-25 19:57 249阅读 0赞

转载：[http://www.cnblogs.com/xubenben/p/4424398.html][http_www.cnblogs.com_xubenben_p_4424398.html]

最近在用java中的ByteBuffer，一直不明所以，尤其是对MappedByteBuffer使用的内存映射这个概念云里雾里。

于是首先补了物理内存、虚拟内存、页面文件、交换区的只是：[小科普——物理内存、页面文件、交换区和虚拟内存][Link 1]

然后阅读了ByteBuffer的文章：[ByteBuffer使用和实现以及文件内存映射][ByteBuffer]。

Bytebuffer分为两种：间接地和直接的，所谓直接就是指MappedByteBuffer，直接使用内存映射（java的话就意味着在JVM之外分配虚拟地址空间）；而间接的ByteBuffer是在JVM的堆上面的，说白了就是管理一群byte数组的包装。

这里面最核心最关键的也即是内存映射了，下面的内容来自这篇文章：[内存映射文件原理探索][Link 2]

内存映射：

# 原理 #

首先，“映射”这个词，就和数学课上说的“一一映射”是一个意思，就是建立一种一一对应关系，在这里主要是只 硬盘上文件 的位置与进程 逻辑地址空间 中一块大小相同的区域之间的一一对应，如图1中过程1所示。这种对应关系纯属是逻辑上的概念，物理上是不存在的，原因是进程的逻辑地址空间本身就是不存在的。在内存映射的过程中，并没有实际的数据拷贝，文件没有被载入内存，只是逻辑上被放入了内存，具体到代码，就是建立并初始化了相关的数据结构（struct address\_space），这个过程有系统调用mmap()实现，所以建立内存映射的效率很高。

![0_1284702135HcPp.gif][]

图1.内存映射原理

既然建立内存映射没有进行实际的数据拷贝，那么进程又怎么能最终直接通过内存操作访问到硬盘上的文件呢？那就要看内存映射之后的几个相关的过程了。

mmap()会返回一个指针ptr，它指向进程逻辑地址空间中的一个地址，这样以后，进程无需再调用read或write对文件进行读写，而只需要通过ptr就能够操作文件。但是ptr所指向的是一个逻辑地址，要操作其中的数据，必须通过MMU将逻辑地址转换成物理地址，如图1中过程2所示。这个过程与内存映射无关。

前面讲过，建立内存映射并没有实际拷贝数据，这时，MMU在地址映射表中是无法找到与ptr相对应的物理地址的，也就是MMU失败，将产生一个缺页中断，缺页中断的中断响应函数会在swap中寻找相对应的页面，如果找不到（也就是该文件从来没有被读入内存的情况），则会通过mmap()建立的映射关系，从硬盘上将文件读取到物理内存中，如图1中过程3所示。这个过程与内存映射无关。

如果在拷贝数据时，发现物理内存不够用，则会通过虚拟内存机制（swap）将暂时不用的物理页面交换到硬盘上，如图1中过程4所示。这个过程也与内存映射无关。

# 效率 #

#  #

从代码层面上看，从硬盘上将文件读入内存，都要经过文件系统进行数据拷贝，并且数据拷贝操作是由文件系统和硬件驱动实现的，理论上来说，拷贝数据的效率是一样的。但是通过内存映射的方法访问硬盘上的文件，效率要比read和write系统调用高，这是为什么呢？原因是read()是系统调用，其中进行了数据拷贝，它首先将文件内容从硬盘拷贝到内核空间的一个缓冲区，如图2中过程1，然后再将这些数据拷贝到用户空间，如图2中过程2，在这个过程中，实际上完成了 两次数据拷贝 ；而mmap()也是系统调用，如前所述，mmap()中没有进行数据拷贝，真正的数据拷贝是在缺页中断处理时进行的，由于mmap()将文件直接映射到用户空间，所以中断处理函数根据这个映射关系，直接将文件从硬盘拷贝到用户空间，只进行了 一次数据拷贝 。因此，内存映射的效率要比read/write效率高。

![0_1284702221pRyi.gif][]

图2.read系统调用原理

[http_www.cnblogs.com_xubenben_p_4424398.html]: http://www.cnblogs.com/xubenben/p/4424398.html
[Link 1]: http://www.guokr.com/blog/62218/
[ByteBuffer]: http://www.molotang.com/articles/997.html
[Link 2]: http://blog.csdn.net/mg0832058/article/details/5890688
[0_1284702135HcPp.gif]: /images/20220226/00db4e2449e64ec09e95984c7ff2f382.png
[0_1284702221pRyi.gif]: /images/20220226/ec7b2252cee64460ac4f04222f3f0391.png