mmap能跳过两次内存拷贝，因为它建立虚拟地址到文件块的直接映射，缺页时内核将磁盘数据装入物理页供进程直接访问，无需从内核页缓存复制到用户空间；而read()需先拷贝至内核页缓存、再拷贝至用户缓冲区。
为什么mmap能跳过两次内存拷贝
传统 read() 调用触发的是标准 I/O 流程：数据先从磁盘加载到内核页缓存（第一次拷贝），再从页缓存复制到用户空间缓冲区（第二次拷贝）。而 mmap 建立的是虚拟地址到文件块的直接映射，CPU 访问映射地址时，由 MMU 和页表完成物理地址解析，缺页时内核直接把磁盘数据装入物理页——这个页，就是进程能直接读写的内存页。没有“复制”，只有“映射”和“按需加载”。
实测中，对一个 1GB 文件只读前 100 字节：read() 耗时约 0.008s，mmap 通常在 0.001–0.002s。差距不是算法快，而是少做了两轮 memcpy。
为什么随机访问大文件必须用mmap
当你需要反复 seek() 到不同偏移量读写（比如解析二进制协议、查索引、patch 某段 header），每次 seek()+read() 都是一次系统调用 + 一次内核态/用户态上下文切换。而 mmap 映射后，mm[offset:offset+8] 就是纯内存访问，CPU 指令级完成，开销几乎为零。
- 适用场景：日志行定位、数据库 WAL 解析、图像元数据提取、自定义二进制格式跳读
- 注意：如果文件未预热（即没被访问过），首次访问某页会触发缺页中断，有延迟；但后续访问同一页就是纯内存速度
- 避免陷阱：不要在 mmap 区域里做
for byte in mm:这种全量遍历——它会强制加载所有页，失去惰性优势
为什么多个进程读同一份大文件时mmap更省内存
多个进程各自 open() 同一个只读文件再 read()，每个进程都有一份独立副本在用户空间。而用 mmap.ACCESS_READ 映射同一文件，操作系统会让它们共享底层物理页帧——只要文件内容不变，内核不会重复加载。
这在微服务或批量任务中特别关键：比如 10 个 Python worker 都要读同一个 2GB 模型权重文件，传统方式吃掉 20GB 物理内存，mmap 可能只占 2GB + 少量页表开销。
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
关键点：mmap 的共享是操作系统级的，不需要额外 IPC 或序列化；但仅限于只读场景。若需写共享，请显式用 flags=mmap.MAP_SHARED 并配合 flush() 控制持久化时机。
为什么mmap不适合小文件或纯顺序读
映射本身有固定开销：页表项分配、VMA（virtual memory area）管理、潜在的文件扩展检查。对几 MB 以下的文件，read() 一次性加载反而更快、更简单。
纯顺序读（如逐行解析日志）也未必受益：现代内核的 read-ahead 已经很激进，read(64KB) 往往比 mmap 的页粒度（通常 4KB）更贴近磁盘块布局，吞吐未必差，还省去维护映射的复杂度。
真正该用 mmap 的信号是：你频繁跳转、局部修改、或多进程共读、或文件远超可用内存。否则，别为了“高级”而换。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
