mmap返回MAP_FAILED的常见原因包括：参数非法（如size为0、offset非页对齐）、权限冲突（prot超出文件打开模式）、fd无效或未调用ftruncate、flags与fd类型不匹配（如shm_open需配MAP_SHARED），以及系统资源不足或大页内存配置缺失。
共享内存映射失败：mmap 返回 MAP_FAILED 的常见原因
多数人卡在第一步——连共享内存都映射不上，mmap 直接返回 MAP_FAILED，errno 却是 EINVAL 或 EPERM。这不是权限问题，而是参数组合不合法。
关键点在于：shm_open 创建的 fd 必须搭配 PROT_READ | PROT_WRITE 和 MAP_SHARED 使用；若用 MAP_PRIVATE，后续写入不会同步到其他进程；若 size 为 0 且未调用 ftruncate，mmap 必然失败。
-
shm_open后必须立即调用ftruncate(fd, size)，哪怕size是 4KB 对齐后的值 - 不要复用普通文件 fd 去
mmap——即使它来自/dev/shm/xxx，也得走shm_open流程 - Linux 下
shm_open路径必须以/开头（如/mydata），不能含点或下划线以外的特殊字符
多进程同步写冲突：为什么 memcpy 到共享内存后另一端读不到新数据
共享内存本身不提供同步语义。写进程 memcpy 完就退出，读进程可能看到旧数据、部分更新的数据，甚至触发 SEGV（如果写进程已 munmap 或 exit 但读进程还持有指针）。
根本原因是：CPU 缓存、编译器重排序、以及没有内存屏障保证可见性。不能依赖 volatile 指针——它只禁用编译器优化，不解决 CPU cache coherency。
立即学习“C++免费学习笔记（深入）”；
- 必须配对使用
__atomic_store_n（写端）和__atomic_load_n（读端），类型选__ATOMIC_SEQ_CST - 更稳妥的做法是用一个独立的
std::atomic<uint64_t></uint64_t>作为“就绪标志”，写完数据后再原子写入长度或版本号 - 避免在共享区内直接放
std::string或std::vector——它们内部指针指向私有堆，跨进程无效
大块数据传输性能瓶颈：为什么 mmap + memcpy 比 sendmsg + unix domain socket 还慢
实测发现，100MB 数据在同机多进程间传输，mmap 方案反而比 sendmsg 慢 15%～20%，问题不在共享内存本身，而在使用方式。
典型错误是每次传输都重新 shm_open + mmap + munmap + shm_unlink。系统调用开销远超 memcpy 本身；而且内核需反复建立页表映射、清理反向映射（rmap）。
- 共享内存段应长期存在（
shm_unlink只在所有进程都退出后由最后一个进程调用） - 用固定大小环形缓冲区（ring buffer）结构，配合两个
std::atomic<size_t></size_t>管理读写偏移，避免频繁系统调用 - 若数据长度变化大，可先传 header（含 size 字段），再按需 memcpy payload，而非预分配最大尺寸
跨平台兼容性陷阱：Windows 上 CreateFileMapping 和 Linux 的差异
代码想同时跑 Linux 和 Windows？别直接封装 mmap 和 CreateFileMapping 成同一接口——底层行为差异太大。
Linux 的 shm_open + mmap 支持匿名、命名、自动清理；Windows 的 CreateFileMapping 要求 HANDLE 必须可继承或显式命名，且 MapViewOfFile 失败时 GetLastError() 返回 ERROR_MAPPED_FILE 很容易被忽略。
- Windows 下必须用全局命名对象（如
L"Global\MySharedMem"），否则受限于会话隔离 - Linux 的
O_EXCL在shm_open中可防重复创建；Windows 需靠OpenFileMapping失败后才调CreateFileMapping - 大小对齐：Windows 要求映射大小是
GetSystemInfo().dwAllocationGranularity（通常 64KB），Linux 只要求页对齐（4KB）
复杂点不在 API 调用，而在于如何让读写双方对“数据就绪”达成一致——这需要共享内存之外的同步原语，且该原语本身也得跨平台。稍不注意，就会在某个平台死锁或假唤醒。
