mmap+MAP_ANONYMOUS(Linux/macOS)或VirtualAlloc(Windows)可实现零磁盘I/O的进程内内存文件系统,支持按需分页、内存保护、共享与动态扩容,天然适配文件语义并兼容fd类系统调用。

直接用 mmap 配合 MAP_ANONYMOUS(Linux/macOS)或 VirtualAlloc(Windows)就能实现零磁盘 I/O 的“内存文件系统”核心——它不是挂载的 FUSE,也不是 tmpfs,而是进程内按需分配、可自由寻址、无文件路径的纯内存字节数组。
为什么不用 malloc?mmap + MAP_ANONYMOUS 的实际优势
表面上看,malloc 也能分配内存;但匿名映射的关键在于:支持按需分页(lazy allocation)、可设置读写/只读/不可执行保护、能跨线程共享(配合 MAP_SHARED)、且可被 mremap 动态扩容(Linux)。更重要的是——它天然适配“文件语义”:你可以用 lseek+read/write 模拟文件操作(通过 memcpy 或指针偏移),甚至伪造 stat 返回假的 size/mtime。
malloc分配的内存无法直接传给需要int fd的系统调用(如sendfile、splice);而mmap区域可通过memfd_create(Linux)封装成真正的fdMAP_ANONYMOUS | MAP_PRIVATE是默认行为,但若需多进程共享数据,请改用MAP_SHARED并确保父进程fork后子进程能访问- 注意:macOS 不支持
MAP_ANONYMOUS,得用MAP_ANON(二者宏值不同,需#ifdef __APPLE__判断)
mmap 分配后如何模拟“文件读写”行为
你不需要真的实现 VFS,只需把映射地址当缓冲区头指针,用偏移+长度做边界检查即可。关键是要统一“当前读写位置”和“逻辑文件大小”,避免越界。
- 维护两个变量:
size_t logical_size(用户认为的文件长度)和char* base_ptr(mmap返回值) read(fd, buf, n)等价于:memcpy(buf, base_ptr + offset, min(n, logical_size - offset)),返回实际拷贝字节数write(fd, buf, n)要先检查offset + n > logical_size,若超限则需用mremap扩容(Linux)或重新mmap+memcpy(跨平台保守做法)- 不要在每次
write后调用msync——除非你明确需要落盘同步;MAP_ANONYMOUS本身就不涉及磁盘,msync在这里是冗余的
Windows 下等效实现:用 VirtualAlloc 替代 mmap
Windows 没有 MAP_ANONYMOUS,但 VirtualAlloc(NULL, size, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE) 效果一致:分配保留+提交的可读写内存页,不关联任何文件句柄。
- 注意
VirtualAlloc的size必须是系统页大小(通常 4KB)的整数倍;不足时需向上取整:((size + 4095) & ~4095) - 扩容只能靠
VirtualAlloc新分配一块更大的内存 +memcpy复制 +VirtualFree释放旧块;没有类似mremap的原子扩容接口 - 若需跨进程共享,必须搭配
CreateFileMapping+INVALID_HANDLE_VALUE(即内存映射文件对象),而非纯VirtualAlloc
真正难的不是分配内存,而是让上层代码无感地把这块内存当“文件”用——比如 libcurl 的 CURLOPT_READFUNCTION、SQLite 的 VFS 层、或者自定义的 std::streambuf。这些地方容易忽略偏移更新、大小截断、以及多线程下 logical_size 的原子更新。别急着封装类,先写个裸指针 + 全局 offset 的原型跑通读写逻辑再说。