C++怎么操作共享内存_C++多进程教程【高效】

现代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> 手动删

共享内存的麻烦不在创建，而在生命周期管理——名字冲突、残留对象、同步缺失、映射状态不一致，这些问题往往在压测或异常退出后才暴露。