传-1作fd导致卡住,因mmap只接受文件描述符而非路径;须先open获取fileno,注意fd生命周期和flush同步,映射大小按页对齐,适用场景为随机访问而非顺序读。

用 mmap 读超大文件时为什么卡在 mmap.mmap(-1, ...)?
因为传了 -1 作为文件描述符(fd),但没先用 os.open() 或 open().fileno() 打开文件。Python 的 mmap.mmap() 不接受路径字符串,只认 fd —— 这是初学者最常卡住的地方。
正确做法是:先以二进制模式打开文件,拿到 fileno(),再传给 mmap。注意不能用 with open(...) as f: 后直接 f.fileno() 然后退出作用域,否则 fd 可能被回收(尤其 Windows 上)。
-
fd = os.open("huge.bin", os.O_RDWR),之后记得os.close(fd) - 或
f = open("huge.bin", "r+b"); mm = mmap.mmap(f.fileno(), 0); f.close()—— 关闭f不影响mm,但别关早了(比如在mmap()前就f.close()) - Linux/macOS 上可设
access=mmap.ACCESS_READ提升只读场景安全性;Windows 上必须匹配打开模式(r+b对应ACCESS_WRITE)
mmap 写入后内容没落盘?
mmap 默认是“延迟写回”,修改内存区域不会立刻刷到磁盘,靠操作系统调度。你改完就退出程序,很可能数据丢了。
- 调用
mm.flush()强制同步:它等价于msync(),确保变更写入文件 - 若需每次写都落盘,加
flags=mmap.MAP_SYNC(仅 Linux 4.15+ 支持,且文件系统需支持 DAX) - 更稳妥的做法是:写完
mm.flush(),再os.fsync(fd)—— 防止内核页缓存还没提交到块设备 - 注意
mm.close()不触发 flush,必须显式调用
处理非整数倍页面大小的文件,len(mm) 和实际文件长度不一致?
因为 mmap 映射区域按系统页对齐(通常是 4KB),如果文件长度不是页大小整数倍,mmap 会把末尾补零映射进来。读取超出原文件长度的位置不会报错,但写入会触发 SIGBUS(Unix)或 AccessViolation(Windows)。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac,无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启:辅助功能 + 屏幕录制权限
- 用
os.path.getsize("file")获取真实长度,别依赖len(mm) - 写入前检查索引:
if pos >= real_size: raise ValueError("write beyond file") - 想安全扩展文件,先
os.ftruncate(fd, new_size),再mm.resize(new_size)(注意resize()不保证跨平台,Windows 不支持)
用 mmap 替代 read() 真的更快吗?
只在特定场景快:随机访问大文件、频繁小范围读写、多进程共享同一文件。顺序读整个文件?反而可能更慢——少了 read-ahead 优化,还多了页表管理开销。
- 纯顺序扫描:老实用
for line in f:或f.read(8192)分块读,mmap没优势 - 需要跳转查找(如解析日志中某时间戳段):
mmap+ 二分搜索比反复seek()快得多 - 多进程同时读同一文件:
mmap.ACCESS_READ共享物理页,省内存;写则需加锁或用mmap.ACCESS_COPY(写时复制) - 注意:32 位 Python 无法 mmap 超过 2GB 文件;64 位下也建议单次映射不超过几 GB,避免虚拟地址空间碎片
真正难的不是调用 mmap,而是判断该不该用、用在哪一段、怎么和文件生命周期配合。映射后忘了 flush,或者映射时没控好 fd 生命周期,比不用还危险。
Python免费学习笔记(深入):立即使用
在学习笔记中,你将探索 Python 的核心概念和高级技巧!










