一、mmap基础概念

mmap 即 memory map，也就是内存映射。mmap 是一种内存映射文件的方法，即将一个文件或者其它对象映射到进程的地址空间，实现文件磁盘地址和进程虚拟地址空间中一段虚拟地址的一一对映关系。实现这样的映射关系后，进程就可以采用指针的方式读写操作这一段内存，而系统会自动回写脏页面到对应的文件磁盘上，即完成了对文件的操作而不必再调用 read、write 等系统调用函数。相反，内核空间对这段区域的修改也直接反映用户空间，从而可以实现不同进程间的文件共享。

(相关资料图)

如下图所示：

mmap的作用，在应用这一层，是让你把文件的某一段，当作内存一样来访问。将文件映射到物理内存，将进程虚拟空间映射到那块内存。这样，进程不仅能像访问内存一样读写文件，多个进程映射同一文件，还能保证虚拟空间映射到同一块物理内存，达到内存共享的作用。

mmap 具有如下的特点：

换言之，CPU 进行一次磁盘读写操作涉及的数据量至少是 4KB，但是进行一次内存操作涉及的数据量是基于地址的，也就是通常的 64bit（64 位操作系统）。mmap 下进程可以采用指针的方式进行读写操作，这是值得注意的。

二. 虚拟内存？虚拟空间？

其实是一个概念，前一篇对于这个词没有确切的定义，现在定义一下：

虚拟空间就是进程看到的所有地址组成的空间，虚拟空间是某个进程对分配给它的所有物理地址（已经分配的和将会分配的）的重新映射。

而虚拟内存，为啥叫虚拟内存，是因为它就不是真正的内存，是假的，因为它是由地址组成的空间，所以在这里，使用虚拟空间这个词更加确切和易懂。（不过虚拟内存这个词也不算错）

虚拟空间原理

物理内存

首先，物理地址实际上也不是连续的，通常是包含作为主存的DRAM和IO寄存器

以前的CPU（如X86）是为IO划分单独的地址空间，所以不能用直接访问内存的方式（如指针）IO，只能用专门的方法（in/read/out/write）诸如此类。现在的CPU利用PCI总线将IO寄存器映射到物理内存，所以出现了基于内存访问的IO。还有一点补充的，就如同进程空间有一块内核空间一样，物理内存也会有极小一部分是不能访问的，为内核所用。

三个总线

这里再补充下三个总线的知识，即：地址总线、数据总线、控制总线

比如CPU通过控制总线发送读取命令，同时用地址总线发送要读取的数据虚地址，经过MMU后到内存

内存通过数据总线将数据传输给CPU。虚拟地址的空间和指令集的地址长度有关，不一定和物理地址长度一致，比如现在的64位处理器，从VA角度看来，可以访问64位的地址，但地址总线长度只有48位，所以你可以访问一个位于2^52这个位置的地址。

虚拟内存地址转换（虚地址转实地址）

上面已经明确了虚拟内存是虚拟空间，即地址的集合这一概念。基于此，来说说原理。

如果还记得操作系统课程里面提到的虚地址，那么这个虚地址就是虚拟空间的地址了，虚地址通过转换得到实地址，转换方式课程内也讲得很清楚，虚地址头部包含了页号（段地址和段大小，看存储模式：页存储、段存储，段页式），剩下部分是偏移量，经过MMU转换成实地址。

存储方式

虚拟地址头部为页号通过查询页表得到物理页号，假设一页时1K，那么页号*偏移量就得到物理地址

虚拟地址头部为段号，段表中找到段基地址加上偏移量得到实地址

二、mmap原理

mmap函数创建一个新的vm_area_struct结构，并将其与文件/设备的物理地址相连。

vm_area_struct：

linux使用vm_area_struct来表示一个独立的虚拟内存区域，一个进程可以使用多个vm_area_struct来表示不用类型的虚拟内存区域（如堆，栈，代码段，MMAP区域等）。

vm_area_struct结构中包含了区域起始地址。同时也包含了一个vm_opt指针，其内部可引出所有针对这个区域可以使用的系统调用函数。从而，进程可以通过vm_area_struct获取操作这段内存区域所需的任何信息。

进程通过vma操作内存，而vma与文件/设备的物理地址相连，系统自动回写脏页面到对应的文件磁盘上（或写入到设备地址空间），实现内存映射文件。

[内核资料领取，](https://docs.qq.com/doc/DTmFTc29xUGdNSnZ2)

[Linux内核源码学习地址。](https://ke.qq.com/course/4032547?flowToken=1044435)

内存映射文件的原理：

首先创建虚拟区间并完成地址映射，此时还没有将任何文件数据拷贝至主存。当进程发起读写操作时，会访问虚拟地址空间，通过查询页表，发现这段地址不在物理页上，因为只建立了地址映射，真正的数据还没有拷贝到内存，因此引发缺页异常。缺页异常经过一系列判断，确定无非法操作后，内核发起请求调页过程。

最终会调用nopage函数把所缺的页从文件在磁盘里的地址拷贝到物理内存。之后进程便可以对这片主存进行读写，如果写操作修改了内容，一定时间后系统会自动回写脏页面到对应的磁盘地址，完成了写入到文件的过程。另外，也可以调用msync()来强制同步，这样所写的内存就能立刻保存到文件中。

mmap内存映射的实现过程，总的来说可以分为三个阶段：

（一）进程启动映射过程，并在虚拟地址空间中为映射创建虚拟映射区域

（二）调用内核空间的系统调用函数mmap（不同于用户空间函数），实现文件物理地址和进程虚拟地址的一一映射关系

（三）进程发起对这片映射空间的访问，引发缺页异常，实现文件内容到物理内存（主存）的拷贝

注：前两个阶段仅在于创建虚拟区间并完成地址映射，但是并没有将任何文件数据的拷贝至主存。真正的文件读取是当进程发起读或写操作时。

注：修改过的脏页面并不会立即更新回文件中，而是有一段时间的延迟，可以调用msync()来强制同步, 这样所写的内容就能立即保存到文件里了。

三、mmap 的 I/O 模型

mmap 也是一种零拷贝技术，其 I/O 模型如下图所示：、

#include <sys/mman.h>void *mmap(void *start, size_t length, int prot, int flags, int fd, off_t offset)

mmap 技术有如下特点：

利用 mmap() 替换 read()，配合 write() 调用的整个流程如下：

通过mmap实现的零拷贝I/O进行了4次用户空间与内核空间的上下文切换，以及3次数据拷贝；其中3次数据拷贝中包括了2次DMA拷贝和1次CPU拷贝

四、mmap 的优势

1.简化用户进程编程

在用户空间看来，通过 mmap 机制以后，磁盘上的文件仿佛直接就在内存中，把访问磁盘文件简化为按地址访问内存。这样一来，应用程序自然不需要使用文件系统的 write（写入）、read（读取）、fsync（同步）等系统调用，因为现在只要面向内存的虚拟空间进行开发。

但是，这并不意味着我们不再需要进行这些系统调用，而是说这些系统调用由操作系统在 mmap 机制的内部封装好了。

（1）基于缺页异常的懒加载

出于节约物理内存以及 mmap 方法快速返回的目的，mmap 映射采用懒加载机制。具体来说，通过 mmap 申请 1000G 内存可能仅仅占用了 100MB 的虚拟内存空间，甚至没有分配实际的物理内存空间。当你访问相关内存地址时，才会进行真正的 write、read 等系统调用。CPU 会通过陷入缺页异常的方式来将磁盘上的数据加载到物理内存中，此时才会发生真正的物理内存分配。

（2）数据一致性由 OS 确保

当发生数据修改时，内存出现脏页，与磁盘文件出现不一致。mmap 机制下由操作系统自动完成内存数据落盘（脏页回刷），用户进程通常并不需要手动管理数据落盘。

读写效率提高：避免内核空间到用户空间的数据拷贝

简而言之，mmap 被认为快的原因是因为建立了页到用户进程的虚地址空间映射，以读取文件为例，避免了页从内核空间拷贝到用户空间。

3.避免只读操作时的 swap 操作

虚拟内存带来了种种好处，但是一个最大的问题在于所有进程的虚拟内存大小总和可能大于物理内存总大小，因此当操作系统物理内存不够用时，就会把一部分内存 swap 到磁盘上。

在 mmap 下，如果虚拟空间没有发生写操作，那么由于通过 mmap 操作得到的内存数据完全可以通过再次调用 mmap 操作映射文件得到。但是，通过其他方式分配的内存，在没有发生写操作的情况下，操作系统并不知道如何简单地从现有文件中（除非其重新执行一遍应用程序，但是代价很大）恢复内存数据，因此必须将内存 swap 到磁盘上。

4.节约内存

由于用户空间与内核空间实际上共用同一份数据，因此在大文件场景下在实际物理内存占用上有优势。

4. mmap 不是银弹

mmap 不是银弹，这意味着 mmap 也有其缺陷，在相关场景下的性能存在缺陷：

5. mmap 的适用场景

mmap 的适用场景实际上非常受限，在如下场合下可以选择使用 mmap 机制：

6.mmap使用细节

在上面的知识前提下，我们下面看看如果大小不是页的整倍数的具体情况：

情形一：一个文件的大小是5000字节，mmap函数从一个文件的起始位置开始，映射5000字节到虚拟内存中。

分析：因为单位物理页面的大小是4096字节，虽然被映射的文件只有5000字节，但是对应到进程虚拟地址区域的大小需要满足整页大小，因此mmap函数执行后，实际映射到虚拟内存区域8192个 字节，5000~8191的字节部分用零填充。映射后的对应关系如下图所示：

此时： （1）读/写前5000个字节（0~4999），会返回操作文件内容。 （2）读字节50008191时，结果全为0。写50008191时，进程不会报错，但是所写的内容不会写入原文件中 。 （3）读/写8192以外的磁盘部分，会返回一个SIGSECV错误。情形二：一个文件的大小是5000字节，mmap函数从一个文件的起始位置开始，映射15000字节到虚拟内存中，即映射大小超过了原始文件的大小。

分析：由于文件的大小是5000字节，和情形一一样，其对应的两个物理页。那么这两个物理页都是合法可以读写的，只是超出5000的部分不会体现在原文件中。由于程序要求映射15000字节，而文件只占两个物理页，因此8192字节~15000字节都不能读写，操作时会返回异常。如下图所示：

此时： （1）进程可以正常读/写被映射的前5000字节(0~4999)，写操作的改动会在一定时间后反映在原文件中。 （2）对于5000~8191字节，进程可以进行读写过程，不会报错。但是内容在写入前均为0，另外，写入后不会反映在文件中。 （3）对于8192~14999字节，进程不能对其进行读写，会报SIGBUS错误。 （4）对于15000以外的字节，进程不能对其读写，会引发SIGSEGV错误。情形三：一个文件初始大小为0，使用mmap操作映射了10004K的大小，即1000个物理页大约4M字节空间，mmap返回指针ptr。

分析：如果在映射建立之初，就对文件进行读写操作，由于文件大小为0，并没有合法的物理页对应，如同情形二一样，会返回SIGBUS错误。但是如果，每次操作ptr读写前，先增加文件的大小，那么ptr在文件大小内部的操作就是合法的。例如，文件扩充4096字节，ptr就能操作ptr ~ [ (char)ptr + 4095]的空间。只要文件扩充的范围在1000个物理页（映射范围）内，ptr都可以对应操作相同的大小。这样，方便随时扩充文件空间，随时写入文件，不造成空间浪费。

五、mmap映射

在内存映射的过程中，并没有实际的数据拷贝，文件没有被载入内存，只是逻辑上被放入了内存，具体到代码，就是建立并初始化了相关的数据结构（struct address_space），这个过程由系统调用mmap()实现，所以建立内存映射的效率很高。 既然建立内存映射没有进行实际的数据拷贝，那么进程又怎么能最终直接通过内存操作访问到硬盘上的文件呢？那就要看内存映射之后的几个相关的过程了。 mmap()会返回一个指针ptr，它指向进程逻辑地址空间中的一个地址，这样以后，进程无需再调用read或write对文件进行读写，而只需要通过ptr就能够操作文件。

但是ptr所指向的是一个逻辑地址，要操作其中的数据，必须通过MMU将逻辑地址转换成物理地址，这个过程与内存映射无关。 前面讲过，建立内存映射并没有实际拷贝数据，这时，MMU在地址映射表中是无法找到与ptr相对应的物理地址的，也就是MMU失败，将产生一个缺页中断，缺页中断的中断响应函数会在swap中寻找相对应的页面，如果找不到（也就是该文件从来没有被读入内存的情况），则会通过mmap()建立的映射关系，从硬盘上将文件读取到物理内存中，如图1中过程3所示。这个过程与内存映射无关。 如果在拷贝数据时，发现物理内存不够用，则会通过虚拟内存机制（swap）将暂时不用的物理页面交换到硬盘上，这个过程也与内存映射无关。mmap内存映射的实现过程：

适合的场景

不适合的场景

示例代码

////  ViewController.m//  TestCode////  Created by zhangdasen on 2020/5/24.//  Copyright © 2020 zhangdasen. All rights reserved.//#import "ViewController.h"#import <sys/mman.h>#import <sys/stat.h>@interface ViewController ()@end@implementation ViewController- (void)viewDidLoad {    [super viewDidLoad];        NSString *path = [NSHomeDirectory() stringByAppendingPathComponent:@"test.data"];    NSLog(@"path: %@", path);    NSString *str = @"test str2";    [str writeToFile:path atomically:YES encoding:NSUTF8StringEncoding error:nil];        ProcessFile(path.UTF8String);    NSString *result = [NSString stringWithContentsOfFile:path encoding:NSUTF8StringEncoding error:nil];    NSLog(@"result:%@", result);}int MapFile(const char * inPathName, void ** outDataPtr, size_t * outDataLength, size_t appendSize){    int outError;    int fileDescriptor;    struct stat statInfo;        // Return safe values on error.    outError = 0;    *outDataPtr = NULL;    *outDataLength = 0;        // Open the file.    fileDescriptor = open( inPathName, O_RDWR, 0 );    if( fileDescriptor < 0 )    {        outError = errno;    }    else    {        // We now know the file exists. Retrieve the file size.        if( fstat( fileDescriptor, &statInfo ) != 0 )        {            outError = errno;        }        else        {            ftruncate(fileDescriptor, statInfo.st_size + appendSize);            fsync(fileDescriptor);            *outDataPtr = mmap(NULL,                               statInfo.st_size + appendSize,                               PROT_READ|PROT_WRITE,                               MAP_FILE|MAP_SHARED,                               fileDescriptor,                               0);            if( *outDataPtr == MAP_FAILED )            {                outError = errno;            }            else            {                // On success, return the size of the mapped file.                *outDataLength = statInfo.st_size;            }        }                // Now close the file. The kernel doesn’t use our file descriptor.        close( fileDescriptor );    }        return outError;}void ProcessFile(const char * inPathName){    size_t dataLength;    void * dataPtr;    char *appendStr = " append_key2";    int appendSize = (int)strlen(appendStr);    if( MapFile(inPathName, &dataPtr, &dataLength, appendSize) == 0) {        dataPtr = dataPtr + dataLength;        memcpy(dataPtr, appendStr, appendSize);        // Unmap files        munmap(dataPtr, appendSize + dataLength);    }}@end

关键词：