mmap返回MAP_FAILED的常见原因包括：/dev/shm空间不足（默认仅4MB）、权限不匹配（如shm_open未用O_RDWR或文件权限不足）、映射长度非页对齐或为0、ftruncate未调用导致文件长度为0、多进程oflag不一致（消费者误加O_CREAT）等。
共享内存映射失败：mmap 返回 MAP_FAILED 的常见原因
直接用 mmap 映射普通文件或 /dev/shm 路径时返回 MAP_FAILED，大概率不是代码写错，而是权限或资源限制问题。Linux 默认对 /dev/shm 有大小限制（通常是 4MB），大数据量下会直接失败。
- 检查当前限制：
df -h /dev/shm或cat /proc/sys/kernel/shmmax - 临时扩容（需 root）：
sudo sysctl -w kernel.shmmax=1073741824（1GB） - 更稳妥的做法是用
shm_open+ftruncate创建命名共享内存段，避免依赖/dev/shm挂载点状态 - 注意
O_CREAT必须搭配mode参数（如0666），否则在某些内核版本下shm_open会静默失败
多进程读写冲突：为什么只加 pthread_mutex_t 不够用
共享内存本身不提供同步语义，pthread_mutex_t 只能在同一进程的多个线程间起作用。跨进程必须用进程间互斥量——即 PTHREAD_PROCESS_SHARED 属性的 mutex，且必须放在共享内存里，不能是栈或堆变量。
- 初始化前必须调用
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED) - mutex 结构体本身要位于共享内存映射区（例如紧跟在数据 buffer 后面），否则各进程访问的是各自副本
- 更轻量的选择是
sem_t（命名信号量），用sem_open("/mysem", O_CREAT, 0666, 1)创建，天然支持进程间，但注意路径名必须以/开头且不能含其他斜杠 - 避免用文件锁（
flock）做同步：它不保证内存可见性，且在 NFS 等场景下行为不可靠
结构体对齐与跨进程兼容性：struct 成员偏移在不同进程里不一致
即使两个进程编译自同一份头文件，若编译选项不同（比如一个开了 -m32，一个用默认 64 位），sizeof(struct) 和成员偏移可能不同，导致写入 A 进程的字段被 B 进程读到错误位置。
- 强制使用标准布局：
#pragma pack(1)或__attribute__((packed))消除填充字节 - 禁用指针成员：共享内存中存指针毫无意义，接收方解引用必段错误
- 用固定宽度类型：
int32_t替代int，uint64_t替代size_t，避免平台差异 - 建议在结构体开头加 magic number 和 version 字段，运行时校验，避免静默数据错位
数据就绪通知机制：轮询 volatile 标志位为什么不可靠
用一个 volatile int ready_flag 放在共享内存里，生产者写 1、消费者轮询等待——看似简单，实际在多核 CPU 上存在缓存一致性延迟和编译器重排序风险，可能永远等不到。
-
volatile只禁用编译器优化，不提供内存屏障，无法保证 store/load 的全局顺序 - 必须配合
std::atomic_thread_fence（C++11）或__sync_synchronize()（GCC）确保写操作对其他核可见 - 更推荐用事件驱动方式：Linux 下用
eventfd（比 pipe 更轻量），或 POSIX 条件变量（需配合共享 mutex 使用） - 如果坚持用标志位，至少用
std::atomic_int并指定memory_order_release/memory_order_acquire
共享内存高效传输的关键不在“怎么映射”，而在“怎么让对方及时、确定、无歧义地知道数据已就绪且格式正确”。很多线上 bug 都藏在结构体对齐、原子语义缺失、或信号量未正确初始化这些细节里，而不是主流程逻辑。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
