现代C++多进程共享内存应优先选POSIX接口（shm_open+mmap），因其路径命名、unlink即时释放、权限模型统一；SysV（shmget+shmat）易因ftok路径错误或IPC_RMDID延迟释放引发问题。
共享内存用 shm_open 还是 shmget？
Linux 下 C++ 多进程共享内存，本质是选 POSIX 还是 SysV 接口。前者用 shm_open + mmap，后者用 shmget + shmat。现代项目优先选 POSIX：路径式命名、支持 unlink 立即释放、与文件系统权限模型一致。
常见错误是混用：比如用 shm_open 创建但误调 shmat，会直接返回 -1 并设 errno = EINVAL。SysV 的 key_t 生成也容易出错——ftok 依赖真实存在的路径，传个不存在的文件名会导致 ftok 返回 -1，后续 shmget 必然失败。
-
shm_open的 name 参数必须以/开头（如"/my_shm"），不能带额外路径分隔符（"/tmp/my_shm"是非法的） - 创建后务必调
ftruncate设置大小，否则mmap会失败并报errno = ENOMEM - SysV 方式下，
shmctl(..., IPC_RMID, ...)只是标记删除，实际内存要等所有进程 detach 后才释放——别以为调了就立刻干净
mmap 映射时 MAP_SHARED 和 MAP_PRIVATE 怎么选？
共享内存必须用 MAP_SHARED。选 MAP_PRIVATE 看似能读写，但修改不会反映到其他进程，相当于每人一份副本——这根本不是共享内存，只是碰巧用了同一段物理内存初始化。
另一个坑是 prot 参数：如果只传 PROT_READ，映射成功，但写入会触发 SIGSEGV；而 PROT_WRITE 单独用也不行，必须和 PROT_READ 按位或（PROT_READ | PROT_WRITE），否则 mmap 直接失败。
立即学习“C++免费学习笔记（深入）”；
- 映射地址建议传
nullptr让内核选，硬指定地址容易冲突，尤其在 ASLR 开启时 - 映射长度必须 ≤
ftruncate设置的大小，超了不会报错，但越界访问行为未定义（大概率段错误） - 多个进程映射同一对象，各自
mmap返回的虚拟地址通常不同，别拿指针值跨进程传递
怎么安全地同步读写？
共享内存本身不提供同步机制。裸用 int flag 做标志位是典型错误——没有内存屏障，编译器和 CPU 都可能重排指令，导致一个进程看到“已就绪”但数据还没写完。
最轻量且可移植的做法是配合 POSIX 命名信号量：sem_open 创建，sem_wait/sem_post 控制临界区。注意信号量名也要以 / 开头（如 "/my_sem"），且需在所有进程间显式关闭（sem_close）和销毁（sem_unlink）。
- 别用局部
std::atomic变量放在共享内存里——它依赖平台内存序保证，但跨进程时缓存一致性由硬件和 OS 共同保障，标准库不承诺跨进程原子性 - 如果必须用自旋锁，得用
__atomic_thread_fence或std::atomic_thread_fence显式加屏障，且初始化要确保所有进程看到一致的初始值 - 信号量初始化：首次创建者应调
sem_init（仅用于匿名信号量）或用sem_open的O_CREAT标志；重复打开无需再 init
程序崩溃后共享内存残留怎么办？
POSIX 共享内存对象（/dev/shm/ 下的文件）不会随进程退出自动清理，尤其崩溃时没调 shm_unlink，下次启动就会 shm_open 失败（errno = EEXIST）。
可靠做法是在 shm_open 时加 O_EXCL 标志，如果失败且 errno == EEXIST，先尝试 shm_unlink 再重试。但要注意：shm_unlink 只删名字，内存仍存在直到最后一个 fd 关闭——所以得确保旧进程确实已死，否则新进程可能读到脏数据。
- 开发期可手动清理：
ls /dev/shm查看，rm /dev/shm/my_shm删除（需权限） - 生产环境建议用带版本号的名称（如
"/my_shm_v2"），避免强制清理影响正在运行的旧实例 - SysV 方式下残留更隐蔽：
ipcs -m查共享内存段，ipcrm -M <shmid></shmid>手动删
共享内存的麻烦不在创建，而在生命周期管理——名字冲突、残留对象、同步缺失、映射状态不一致，这些问题往往在压测或异常退出后才暴露。
