Golang中的内存映射文件(Mmap) Go语言高性能大文件访问技术

go 中不能直接用 syscall.mmap，因其不处理平台差异、页对齐、错误映射及生命周期管理，且 gc 不感知内存绑定，易致 sigbus 或 panic；windows 无真正 mmap 支持，linux/macos 要求 offset 页对齐。

为什么 mmap 在 Go 里不能直接用 syscall.Mmap 就完事？

Go 标准库没封装 mmap，syscall.Mmap 是底层裸接口，不处理平台差异、页对齐、错误码映射，更不管理生命周期。直接调用容易 panic 或静默失败。

• syscall.Mmap 返回的 []byte 底层数组和虚拟内存绑定，但 Go 的 GC 不知道这块内存不能动，若切片被回收或重用，可能触发 SIGBUS
• Windows 上要用 VirtualAlloc + MapViewOfFile，不是 mmap 语义，syscall.Mmap 在 Windows 是 stub，直接调用会报 ENOSYS
• Linux/macOS 要求 offset 必须是页大小（通常 4096）整数倍，传错会返回 EINVAL，而文件开头偏移为 0 是安全的，但读中间块时极易踩坑

推荐用 golang.org/x/exp/mmap（虽处 exp 下，但已稳定用于生产），它自动处理对齐、跨平台映射、并提供 Unmap 显式释放。

读大文件时，mmap 真比 os.ReadFile 快？

不一定。小文件（mmap 反而更慢：多了系统调用开销、页表建立、缺页中断；真正受益的是随机访问 >100MB 的只读场景，比如日志索引、二进制数据库。

• os.ReadFile 会一次性 malloc 内存 + read(2)，适合顺序读、内存充足、文件可载入
• mmap 按需加载（lazy fault），首次访问某页才从磁盘拉，内存占用低，但随机跳读多时，缺页中断频繁，延迟毛刺明显
• 若文件被其他进程截断或删掉，mmap 区域会变成 SIGBUS，而 ReadFile 早已经拿到副本，更“钝感”

示例：读取 2GB 日志中第 1.5GB 处的 1KB 数据

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

data, _ := mmap.Open("/var/log/app.log") defer data.Unmap() // 直接 slice 访问，无需 seek + read chunk := data.Bytes()[1500*1024*1024 : 1500*1024*1024+1024]

mmap 写文件时，为什么改了内存但磁盘没更新？

因为默认是 MAP_PRIVATE（写时复制），修改只影响当前进程虚拟内存，不落盘。要持久化，必须：

• 创建时用 MAP_SHARED 标志（mmap.OpenFlag 中设 mmap.RDWR | mmap.SHARED）
• 修改后调用 msync —— Go 的 golang.org/x/exp/mmap 提供 Flush() 方法，本质是 msync(MS_SYNC)
• 不调 Flush，仅靠 Unmap 无法保证写入，内核可能延迟刷盘甚至丢数据（尤其断电）

常见错误现象：程序退出后文件内容仍是旧的，或另一进程读不到最新修改。
注意：msync 是阻塞系统调用，高频写时别每改一次就 flush，可批量改完再 flush，或依赖内核后台回写（但不可靠）。

用 mmap 做进程间共享内存靠谱吗？

可以，但别绕过同步机制。Linux/macOS 下 mmap + MAP_SHARED + 同一个文件路径，确实能让多个进程看到同一块内存，但：

• 文件必须存在且有读写权限，且所有进程用相同 offset 和 Length 映射，否则视图错位
• Go 的 runtime 不保证对共享内存的原子操作（如 int64 写），需用 sync/atomic 或 mutex 配合 unsafe.pointer 手动操作
• Windows 上需用 CreateFileMapping + OpenFileMapping，语义不同，x/exp/mmap 不支持跨进程共享，得换方案（如 github.com/edsrzf/mmap-go）

最易忽略的一点：没有文件锁或信号量，纯靠内存地址通信，一旦某个进程 panic 未清理状态，其他进程可能读到脏/中间态数据。实际项目中，建议只用 mmap 共享只读数据，读写协调仍走管道或 socket。