mmap返回MAP_FAILED的常见原因是ENOMEM（内存不足）和EACCES（权限不足），如/dev/shm空间不足、shm_open未用O_RDWR、文件权限不匹配、映射长度非页对齐或为0。
共享内存映射失败：mmap 返回 MAP_FAILED 的常见原因
直接用 mmap 映射共享内存（如 /dev/shm/mydata）时返回 MAP_FAILED，八成不是代码写错，而是权限或路径问题。Linux 下 /dev/shm 默认挂载为 size=64M，超大块（比如 512MB）会直接失败，且不报具体原因。
- 先检查
df -h /dev/shm，确认剩余空间；不够就重新挂载：sudo mount -o remount,size=2G /dev/shm -
shm_open后必须调用ftruncate(fd, size)，否则mmap会因文件长度为 0 失败 - 多进程访问同一对象时，
shm_open的oflag要一致：生产者用O_CREAT | O_RDWR，消费者必须用O_RDWR（不能带O_CREAT），否则可能静默创建新对象导致映射错位
用 pthread_mutex_t 在共享内存中做跨进程锁？别这么干
pthread_mutex_t 默认只支持线程内互斥，跨进程必须显式初始化为进程共享模式，且依赖 PTHREAD_PROCESS_SHARED 属性——但很多旧版 glibc 或 musl 不完全支持，实测容易死锁或崩溃。
- 更稳的方案是用
sem_t：通过sem_open("/mysem", O_CREAT, 0644, 1)创建命名信号量，sem_wait/sem_post天然支持进程间同步 - 若坚持用互斥量，必须在共享内存里分配并用
pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED)设置属性，且所有进程需在映射后、首次使用前完成初始化（不能靠静态初始化） - 注意：
pthread_mutex_destroy必须由最后一个退出的进程调用，否则残留状态会导致下次打开失败
数据块传输时如何避免“读到半截数据”？结构体对齐与原子写入边界
共享内存里放一个 struct { uint64_t version; char data[1024*1024]; }，生产者改完 data 就更新 version，消费者轮询 version 变化——这看似合理，但 x86 上 uint64_t 写入是原子的，ARMv7 可能不是；更麻烦的是编译器或 CPU 重排，导致 data 写了一半 version 就先被刷到内存。
- 强制内存序：生产者末尾加
__atomic_store_n(&header->version, new_ver, __ATOMIC_RELEASE)，消费者开头用__atomic_load_n(&header->version, __ATOMIC_ACQUIRE) - 结构体打包必须显式指定：
struct __attribute__((packed)) header { ... };，否则编译器填充字节会让version地址不对齐，影响原子性 - 如果数据块超过缓存行（通常 64 字节），避免把
version和高频更新字段放在同一缓存行，否则引发 false sharing，性能反降
销毁共享资源时的竞态：谁该删 shm_unlink？
shm_unlink 删除的是名字，不是内存本身；只要还有进程持有着 fd 或映射地址，内存就一直存在。但若生产者退出前删了名字，消费者再开同名对象就会新建，导致后续通信失效。
立即学习“C++免费学习笔记（深入）”；
- 约定由“最后退出的进程”负责
shm_unlink，可用sem_wait配合计数信号量实现退出协调 - 更简单做法：不调
shm_unlink，让系统在所有进程退出后自动回收（/dev/shm下对象生命周期绑定于引用计数） - 调试时可用
ipcs -m查看共享内存段，ipcs -s查信号量；残留对象用ipcrm -M <shmid></shmid>手动清理
跨进程共享内存真正难的从来不是映射或拷贝，而是边界条件下的状态可见性与资源生命周期管理——比如一个没被 __ATOMIC_RELEASE 保护的版本号更新，或者两个进程都以为对方会删 shm_unlink 而谁都没删。
