如何使用Golang进行文件的内存映射(Mmap)_高性能IO

go标准库无跨平台mmap支持，需用syscall或github.com/edsrzf/mmap-go；mmap返回的[]byte不可append、需显式unmap，适用于大文件随机读，不适用于小文件或顺序读。

Go 里 mmap 没有标准库支持，得用 syscall.Mmap 或第三方包

Go 标准库不提供跨平台的内存映射封装，os.File 的 ReadAt/WriteAt 走的是系统调用路径，不是真正的 mmap。真要 mmap，必须直连底层 syscall —— linux/macos 用 syscall.Mmap，windows 得用 syscall.VirtualAlloc + syscall.CreateFileMapping 等组合，非常繁琐。

实操建议：

• 优先考虑 github.com/edsrzf/mmap-go：它封装了各平台差异，API 统一，且维护活跃；go get github.com/edsrzf/mmap-go 即可引入
• 别自己手写 syscall.Mmap 调用：参数顺序、flag 含义（如 syscall.PROT_READ vs syscall.MAP_SHARED）、页对齐检查都容易出错
• 注意该包返回的 mmap.MMap 是 []byte，但底层指向虚拟内存，不能直接传给 copy 或 json.Unmarshal 等可能触发 GC 扫描的函数（见下一条）

mmap 映射后不能随意 append 或当普通切片用

映射出来的内存区域是固定大小、与文件强绑定的。你拿到的 []byte 是一个“视图”，底层数组头指向 mmap 地址，但它的 cap 并不反映真实可用空间，append 会 panic 或静默失败。

常见错误现象：

立即学习“go语言免费学习笔记（深入）”；

• runtime Error: index out of range [x] with Length y：试图越界写入映射区外
• panic: runtime error: makeslice: cap out of range：对 mmap 返回的 slice 做 append
• 写入后文件没更新：忘了用 MAP_SHARED（Linux/macOS）或没调 FlushViewOfFile（Windows）

正确做法：

• 只用 slice[i]、copy(dst, mm[:n]) 这类不改变底层数组结构的操作
• 写入前确认 flag 是 mmap.RDWR（对应 PROT_READ|PROT_WRITE）且 mmap.SHARED（否则修改不会落盘）
• 写完记得调 mm.Flush()（mmap-go 提供），尤其在程序退出前，避免脏页丢失

大文件随机读性能提升明显，但小文件或顺序读反而更慢

mmap 的优势在于避免内核态/用户态数据拷贝，适合频繁随机访问固定区域的大文件（比如数据库索引、日志检索）。但它有启动开销：首次访问会触发缺页中断，建立页表映射；而且整个映射区会占用进程的虚拟地址空间（虽不占物理内存，但 32 位进程易撞到 4GB 限制）。

使用场景判断：

• ✅ 适合：100MB+ 文件、需要按 offset 频繁跳读（如解析 protobuf message by tag）、多 goroutine 并发读同一块只读区域
• ❌ 不适合：小于 1MB 的文件（系统调用开销反超）、纯顺序流式读（bufio.Scanner 更轻量）、需加密/解压后再处理的场景（mmap 无法介入中间过程）
• ⚠️ 注意：Linux 下 mmap 默认启用 MAP_POPULATE 会预加载所有页，导致启动卡顿；生产环境建议用 mmap.FLAG_NO_RESERVE 或手动 madvise(MADV_WILLNEED)

关闭映射必须显式调 mm.Unmap()，否则资源泄漏

Go 的 GC 不管理 mmap 分配的虚拟内存。不调 Unmap()，进程的 VMA（virtual memory area）条目会一直存在，Linux 下表现为 /proc/PID/maps 里持续增长，最终可能触发 ENOMEM。

实操要点：

• 务必在 defer mm.Unmap()，尤其在函数早 return 路径上
• 不要依赖 finalizer：GC 触发时机不确定，Unmap 太晚会导致文件被锁住（Windows）或 mmap 区域残留
• 如果映射用于长期服务（如配置热加载），每次 reload 必须先 Unmap 旧的，再 Mmap 新的；重复映射同一文件不同 offset 不冲突，但同一 offset 多次映射会增加 VMA 数量

最常被忽略的一点：mmap 的生命周期和文件句柄无关。即使 os.File.Close() 了，只要 mm.Unmap() 没调，映射依然有效——这既是灵活性，也是泄漏温床。