mmap不能直接映射增长中的大文件，因其映射长度需调用时固定且按页对齐，文件扩容后原映射不会自动延伸，访问越界会触发SIGBUS或段错误；必须预分配空间并采用定长结构设计。
mmap 本身不直接解决“亿级数据极速持久化”的问题，它只是提供一种低开销访问文件内容的机制。真正能扛住亿级规模、兼顾速度与可靠性的，是围绕 mmap 构建的结构化设计——比如固定长度记录布局、预分配文件大小、避免动态扩容、配合 msync 控制刷盘时机。盲目用 mmap 映射一个不断追加的变长日志文件，反而会触发大量缺页中断和写时拷贝，性能比 write 还差。
为什么不能直接 mmap 一个增长中的大文件？
Linux 的 mmap 要求映射长度在调用时就确定，且必须按页对齐（通常是 4KB）。如果文件后续被 write 或 ftruncate 扩容，已有的映射区域**不会自动延伸**；继续访问超出原 length 的地址会触发 SIGBUS 或段错误。
常见错误现象：
- 程序运行一段时间后突然 crash，报错
Bus error (core dumped) -
mmap返回成功，但读到末尾全是零（因为文件实际 size 小于映射 length，内核自动补零） - 多个进程同时写入同一文件，没加锁导致记录覆盖或错位
所以亿级场景下，必须提前规划好最大容量，并用 ftruncate 一次性分配好磁盘空间：
import os
import mmap
<h1>预分配 10GB 文件（假设每条记录 128 字节，共 ~80M 条）</h1><p>size = 10 <em> 1024 </em> 1024 * 1024
with open("data.bin", "w+b") as f:
f.truncate(size) # 关键：先占坑，避免碎片和扩容
mm = mmap.mmap(f.fileno(), size, access=mmap.ACCESS_WRITE)</p>如何设计固定结构让 mmap 真正“极速”？
随机访问快的前提是：能用 id 直接算出字节偏移。这就要求所有记录等长、无指针、无变长字段（如字符串需定长 buffer 或外置索引）。
典型结构示例（每条 128 字节）：
- bytes 0–7：int64 id（主键）
- bytes 8–15：int64 timestamp
- bytes 16–115：fixed-length payload（100 字节，不足补空格）
- bytes 116–127：reserved（预留扩展）
这样查 id=12345 就是：mm[12345 * 128 : 12345 * 128 + 128]，一次内存寻址完成，不涉及系统调用。
注意：mmap.ACCESS_WRITE 模式下修改内存不会立即落盘，靠内核异步回写。若需强持久化（如金融交易），必须显式调用 msync：
# 修改第 100 万条记录后强制刷盘 offset = 1_000_000 * 128 mm[offset:offset+8] = (12345).to_bytes(8, 'little') mm[offset+8:offset+16] = int(time.time()).to_bytes(8, 'little') mm.flush() # 或更精准地：mm.msync(offset, 128, mmap.MS_SYNC)
Python mmap 在高并发写入时容易踩哪些坑？
Python 的 mmap 对象不是线程安全的——多个线程同时写同一片区域会破坏数据。它也不支持进程间原子操作（比如 CAS）。
关键限制：
-
mmap本身不提供锁，threading.Lock只能保护 Python 层逻辑，无法防止两个进程同时修改同一物理页 - 使用
MAP_SHARED时，不同进程看到的是同一份内存，但写入冲突需自行处理（比如用文件锁flock或基于 offset 的分段写入） - 32 位 Python 进程虚拟地址空间有限（约 2–3GB），映射超过此大小会失败；64 位则无此硬限，但要注意 RSS 增长是否引发 OOM
建议做法：
- 单写多读场景：用
fcntl.flock控制写入权，读端直接 mmap 并发访问 - 多写场景：拆成多个固定大小的子文件（如
shard_0001.bin），按 key hash 分片，避免锁竞争 - 避免在 mmap 区域内做
struct.unpack等频繁小对象解析——先把整块 bytes 切出来再处理，减少引用计数开销
什么时候该放弃 mmap，换回普通 write？
不是所有“大文件”都适合 mmap。以下情况直接用 write + 缓冲更稳更快：
- 记录长度不固定（JSON 行、Protocol Buffers 序列化结果）
- 写入模式是持续追加（log-style），且不关心随机读
- 目标存储是网络文件系统（NFS）、FUSE、或移动设备上的闪存（iOS/Android 不保证 mmap 同步语义）
- 单次写入量远小于页大小（如每次只写 16 字节），mmap 的页表管理开销反而更高
一个朴素但有效的判断标准：如果你需要 seek() + read() 随机跳转上百次/秒，且记录可定长，mmap 才值得投入；否则先 benchmark open().write() 和 mmap 在你真实硬件上的 p99 延迟。
