不能直接用普通指针操作mmap返回地址，因为其生命周期、同步时机和访问边界由mmap管理，非普通堆内存；需显式munmap、msync，且越界或解引用失效地址会触发SIGSEGV。
为什么不能直接用普通指针操作 mmap 返回的地址
mmap 返回的是 void*，它指向操作系统分配的一段虚拟内存，这段内存背后关联着文件或匿名区域。你当然可以用 static_cast<T*> 转成具体类型的指针来读写，但关键在于：**这不是普通堆内存，它的生命周期、同步时机和访问边界都由 mmap 管理**。常见错误是转成指针后忘了 msync 就退出，或者越界读写触发 SEGV_MAPERR 信号。
真正要警惕的是：C++ 的 new/delete、std::vector、智能指针等完全不感知 mmap 内存——它们不会帮你 munmap，也不会阻止你在未映射区域解引用。
如何安全地把 mmap 地址转成可读写的结构体指针
假设你映射了一个二进制文件，其内容是连续的 struct Record，最直接的方式是强制类型转换，但必须确保对齐、大小和端序一致：
struct Record {
uint32_t id;
char name[32];
};
<p>int fd = open("data.bin", O_RDONLY);
void<em> addr = mmap(nullptr, file_size, PROT_READ, MAP_PRIVATE, fd, 0);
if (addr == MAP_FAILED) { /</em> handle error */ }</p><p>// 安全转换的前提：
// - file_size 是 sizeof(Record) 的整数倍
// - 文件数据按小端序写入（与当前平台一致）
// - 没有 padding 差异（建议加 static_assert 或 #pragma pack(1)）
Record<em> records = static_cast<Record</em>>(addr);</p><p>// 使用示例：读第 5 条
if (5 < file_size / sizeof(Record)) {
printf("id = %u\n", records[5].id);
}
- 别用
reinterpret_cast—— 它绕过类型检查，static_cast更明确且编译器能报错 - 结构体里避免指针成员，因为 mmap 后指针值在不同进程/重启后失效
- 如果文件来自其他平台，先校验
id字段是否合理，再继续访问后续字段
PROT_WRITE 和 msync 的实际影响
即使你用 PROT_READ | PROT_WRITE 映射，修改内存也不会自动写回文件。必须显式调用 msync，否则：进程崩溃时修改丢失；其他进程通过同一文件映射看不到变更；munmap 不保证刷盘。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
msync(addr, len, MS_SYNC)：阻塞直到数据落盘（慢，但强一致） -
msync(addr, len, MS_ASYNC)：只提交到内核页缓存，返回快，但不保证何时写磁盘 - 频繁写入时，避免每次改一个字节都
msync，攒一批再刷；或改用MAP_SHARED | PROT_WRITE配合定期刷 - 若映射时用了
MAP_PRIVATE，msync无效——那是写时复制副本，改了也只影响当前进程
munmap 后还能用那个指针吗
不能。一旦调用 munmap(addr, len)，该虚拟地址空间立即失效。后续任何读写都会触发 SIGSEGV（除非你捕获并处理，但不推荐）。更隐蔽的问题是：没 munmap 就退出进程，虽然内核会回收，但长期运行的服务容易耗尽虚拟内存地址空间（尤其在 32 位环境）。
典型疏漏点：
- 在异常路径（如
throw）中忘记munmap - 用 RAII 封装时，析构函数里调
munmap，但没检查addr != MAP_FAILED - 多线程共享映射地址，一个线程
munmap后其他线程还在用——mmap 地址在同进程内是全局可见的，但munmap只解除当前调用线程的映射关系？错，它是进程级操作，所有线程立刻失效
最稳妥的做法：映射成功后立刻用 RAII 包一层，确保 munmap 在作用域结束时执行，且构造失败时不尝试释放。
