msync是数据持久化的必要环节，而非可选优化；必须在写完关键数据、多进程依赖写入顺序、或使用MAP_SHARED映射时显式调用，以确保修改落盘；MS_SYNC阻塞至磁盘写入完成，MS_ASYNC仅标记脏页交由内核异步处理。
msync 什么时候必须调用
写入内存映射文件后，msync 不是“可选优化”，而是**数据持久化的必要环节**——尤其当你需要确保修改已落盘（比如防止进程崩溃或断电丢数据）。默认情况下，mmap + write（或直接改映射内存）只是更新页缓存，内核按需回写，时间不可控。
以下场景必须显式调用 msync：
- 写完关键数据（如数据库事务日志、配置快照）后要立即保证磁盘可见
- 多个进程通过同一文件映射协作，且依赖写入顺序可见性
- 使用
MAP_SHARED映射，但未设置MS_SYNC或MS_ASYNC标志
msync 的 flags 怎么选：MS_SYNC vs MS_ASYNC
msync 行为由第二个参数 flags 决定，核心就两个选项，别混用：
-
MS_SYNC：阻塞调用，直到对应内存页完成**写入磁盘**（含设备缓存刷出），适合强一致性要求；但可能卡住几毫秒到几十毫秒（尤其机械盘或高负载 SSD） -
MS_ASYNC：仅把脏页标记为“待回写”，立刻返回，由内核后台线程处理；不保证落盘时机，也不能替代fsync对文件元数据的保护 - 不传 flag（即 0）等价于
MS_ASYNC，但语义模糊，建议显式写出
注意：MS_SYNC 并不自动刷新文件大小变更（如 ftruncate 后扩展的部分），这部分仍需 fstat 或 fsync 配合。
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
为什么只 msync 还不够：元数据和文件大小问题
即使你用 msync(addr, len, MS_SYNC) 把所有数据页刷到了块设备，仍有两件事没做完：
- 文件大小（
st_size）变更不会被msync覆盖 —— 比如你先ftruncate扩大文件，再映射写入，msync不保证新 size 被持久化 - 目录项和 inode 元数据（如 mtime、ctime）也不归
msync管，它们仍缓存在 page cache 中
所以安全做法是：
- 如果文件大小变了，
msync后补一次fsync(fd)（对文件描述符调用） - 如果只改内容、大小不变，
msync(MS_SYNC)通常足够（但注意：某些旧内核或 ext2/ext3 下仍建议fsync双保险） - 避免在
msync前 close 文件描述符 —— 它不依赖 fd，但后续fsync需要
实际写法示例与常见坑
典型流程代码片段（省略错误检查）：
int fd = open("data.bin", O_RDWR | O_CREAT, 0644);
ftruncate(fd, 1ULL << 30); // 1GB
void* addr = mmap(nullptr, 1ULL << 30, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
<p>// 写入数据...
memcpy(addr, data, size);</p><p>// 关键：同步数据页
msync(addr, size, MS_SYNC);</p><p>// 如果 ftruncate 过，这里必须 fsync
fsync(fd);</p><p>munmap(addr, 1ULL << 30);
close(fd);</p>容易踩的坑：
- 对
MAP_PRIVATE映射调用msync—— 无效，它只影响私有副本，不涉及底层文件 - 传给
msync的地址/长度没对齐到页面边界（getpagesize()）—— 多数系统会自动向下取整，但行为未标准化，建议手动对齐 - 多线程并发写同一映射区域，又没加锁，
msync只保证“已写入部分”落盘，不解决竞态本身 - 在容器或某些虚拟化环境中，
MS_SYNC可能被降级为MS_ASYNC（取决于存储驱动），需实测验证
真正麻烦的从来不是调不调 msync，而是得想清楚：你到底要“哪部分”落盘、在“什么时间点”之前必须完成、以及“谁来负责校验成功”。
