假如当下的场景里存在一项具体任务, 那就是需要对一个容量达到20G的巨型文件进行一系列处理操作。在此情境之下, 我们究竟应当采取何种方式来妥善完成这一工作并对其进行深入思考与探讨, 进而构思出实现该功能的具体路径与方案呢?咱们大概会采用这么一种办法来进行实现。def get_datas():source_text_path 路径with open(source_text_path, rb) as f:data f.readlines()yield dataif __name__ __main__:for e in get_datas():deal_data(e) # 处理数据这样虽然能实现, 但是我们处理的时候需要消耗的资源和性能不是很友好, 所以我们要优化, 也就是使用mmap模块。mmap这种技术, 属于一种可以把文件或者其他对象, 映射到进程地址空间里面的方法, 它能够实现什么呢, 就是可以实现文件在磁盘上面的地址, 和这个进程的虚拟地址空间里面的一段虚拟地址, 两者之间的一种一一映射的关系。该机制省去了在内核态与用户态之间执行页副本复制这一动作, 也就是两态之间的数据copy。它直接将属于用户态的虚拟地址映射到内核态的空间范围内, 使得进程可以直接读取处于内核空间内的数据, 这样的话速度的确提高了, 同时内存占用量也就变少了。说得更直白一点, mmap这个函数的功能是完成内存的共享操作, 而内存共享指的其实就是两个互不相关的进程去共享同一块内存区域这一现象, 其核心含义是那块实实在在的物理内存在被预先规定好具体大小以及特定名称之后, 会被同时将两个进程各自的地址空间进行映射连接起来, 并且在这过程中, 所规定的内存大小必须严格大于最终实际写入内容的体积。当处于需要执行写入操作的情形下, 首先要确认内存的名称, 随后将数据写入该内存区域。等到后续需要进行读取操作时, 首要任务明确知晓预期读取数据的长度, 其根本原因在于物理内存的实际容量往往大于所需读取的数据量, 倘若选择进行全量读取, 势必会导致额外捕获到毫无意义的无效空内容, 在完成上述大小确认后, 接着去定位匹配名称的物理存储块, 最后才正式执行读取动作。mmap 介绍mmap.mmap(fileno, length, tagnameNone, accessACCESS_DEFAULT[, offset])参数说明Unixmmap.mmap(fileno, length, flagsMAP_SHARED, protPROT_WRITE|PROT_READ, accessACCESS_DEFAULT[, offset])参数说明文件描述符有如下支持的方法针对eof这种情形的处理办法, write函数以及括号里面没填写的函数会抛出异常错误信息, 而另外两个括号里没写名的输入输出操作函数和read函数则不会进行任何额外的处理动作。使用mmap读取大文件from mmap import mmapdef read_data(file_path):with open(file_path, r) as f:m mmap(f.fileno(), 0)g_index 0for index, char in enumerate(m):if char b\n:yield m[g_index:index 1].decode()g_index index 1if __name__ __main__:file_path for content in read_data(file_path):print(content)什么时候用mmap用mmap方式来读取那些体积非常庞大的文件, 这其实并不属于mmap的主要使用场景。官方文档里面根本就没有提到过这样做的事情。如果只是单纯地去读取一个超级大的文件的话, 直接使用文件对象里面的read(N)这个方法, 实际上会来得更加快速、效果更加良好、过程也更加简单。关于标准库当中那个mmap模块的情况。现在有具体的需求是需要对特别大的文件进行读写操作, 这个文件的大小接近40G。像这种工具会直接拒绝打开这么大一个文件。如果用r模式把文件打开的话, 是可以随意地去读或者写数据的, 但是必须特别地小心。某个判断是否能够使用, 这个条件要看每一个文件每一行到底有多长, 如果里面完全没有换行的话, 那就是不能用的。哪怕是知道了每一行的具体大小情况下去操作, 也需要带上一个参数N来去控制最大读取的数量。那个括号肯定是绝对不能使用的, 哪怕带有参数, 也有可能导致系统直接出现卡死的情况。使用读取N这个操作本身是没有问题的, 关键在于主要需要控制的是变量N的大小。总而言之, 大家还是可以用传统的那些读写文件的方法的。只不过这样操作起来会显得不怎么方便。还有一个问题就是关于速度的。那些老一套的缓存IO方式, 是会在操作系统的内核态内存和进程自己的虚拟空间内存之间交换数据的。要是遇到那些特别大的文件的话, 这种交换动作就会导致大量的CPU时间还有内存都被白白浪费掉的。那么 mmap 这种方式也是存在的一个替代选项它省掉了内核态和用户态页拷贝这个动作, 也就是所谓的两态间copy, 直接将用户态的虚拟地址与内核态空间进行映射, 这样进程可以直接读取内核空间, 结果是速度提高了, 内存占用也少了。总的来讲, 常规的文档存取动作为了提升读写的速度和保障硬盘的安全, 选择了页缓存这一机制。如此安排使得读取文件时, 首先要做的就是把文件的相应部分从硬盘里复制到页缓存里面去。考虑到页缓存位于内核空间之中, 用户程序没办法直接去访问它所在的地址范围。因此, 必须将页缓存里面的数据再一次复制到了属于用户空间的内存对应位置上去。经过这两轮数据搬运的流程之后, 进程总算能够拿到文件里的具体内容了。写操作的做法也完全相同, 因为那些准备要写入的数据目前待在核心区域里, 普通的程序是没权限直接去碰它们、读写它们的, 所以系统非得先把这些内容从那个地方搬运到对应的主内存中去, 等事情处理完了, 再统一把它们存放到硬盘上去, 这种策略在专业术语里被称作延迟写回, 而在整个过程中, 数据总共也被复制了两遍。在使用mmap操作文件时, 创建新的虚拟内存区域以及建立文件磁盘地址和虚拟内存区域之间映射关系的这两个步骤中, 没有任何的文件拷贝操作发生。当进程之后访问数据时如果发现内存里面并没有数据, 从而触发缺页异常处理过程, 这一过程可以借助于之前已经建立好的映射关系, 仅执行一次数据拷贝动作, 就能够把数据从磁盘之中传入到内存的用户空间中, 最终供进程进行使用。总而言之, 常规的文本文件操作行为, 需要经历从硬盘设备驱动所管理的物理存储区域到操作系统内核维护的页面缓存区域, 再到应用程序运行时所使用的主内存区域的两次数据复制过程。相对于此而言, 采用mmap映射机制来操控文件内容的话, 则仅仅需要完成单次的数据复制动作, 这次动作是直接连接了外部存储介质和主内存之间的数据传输路径的。说得再直白一点的话, mmap这种技术的核心要点在于达成了用户态程序所在空间与内核态操作系统所在空间内部数据流的直通访问能力, 从而规避掉了因涉及不同权限层级隔离而导致必须进行额外拷贝所带来的效率损耗问题。由此可见, 在某些特定的应用情境当中, 选用mmap方式来进行输入输出处理的效率是相对较高的。去官网查看关于mmap的介绍可以发现, 生成的那个mmap对象看起来就像一个普通的对象一样, 用户可以直接使用index的方式来进行读写操作, 当然也可以对数据进行切片处理。与此同时, 这个mmap对象还提供了一组类似于文件操作的接口, 比如像read这样的读取方法, 还有像flush这样的刷新方法等等。也就是说, 这个mmap对象的功能和file对象的功能是兼具的。不过还是要多加注意, 在处理那些体积特别巨大的文件的时候, 仅仅去读取数据, 暂时不去考虑写这块的事情就行, 因为数据从磁盘传到内核的过程中, 依然是会占用到内存空间的, 所以绝对不可以一下子全都给读出来这一点是非常明确的, 必须得通过反复调用read函数并且指定读取N个字节的方式来操作才行, 至于说用mmap这种方式, 它存在的意义只是在于有可能会把效率给提高一些罢了, 但是如果频繁地去创建以及去关闭所谓的mmap映射的话, 这种创建操作的目的是为了让你能够指向超大文件里面不同的位置区域, 这样一来反而会让整体的运行效率变得更低一些了。在通常情况之下, 实现读取N个字节的内容时, 一般是不需要进行内存映射操作的。)。mmap这一技术还有另外一个常见的用处, 那就是让不同的进程去共享同一片内存空间, 具体的实现方式很简单, 就是把同一个文件分别映射到各自的内核地址区间里面去, 这样一来的话, 各个进程之间就能够共同地去访问这片内存区域了。总结使用mmap的时机当一个普通文件被映射到内存里面的时候, 通常是会在需要对文件进行频繁的读写操作的时候使用这种做法的, 这样一来, 用内存映射的方式进行读写的这个操作, 取代了原本那个I/O缓存进行的读写的那个操作的方式, 从而能够获得一个相对比较高的一个性能水平。先把那些特殊的文件, 拿来做一个匿名内存映射的操作, 这么干的话, 就能够给那些相关的进程, 提供一个可以共享的内存空间。它会给那些彼此之间没关系的进程提供可以共享的内存空间, 通常情况下也是会把一个普通的文件映射到内存里面去。