嘿，这问题问得挺到位——SysV和POSIX共享内存虽然都是Linux上实现进程间内存共享的方案，但底层逻辑差得老远，咱们拆成两个问题一个个说清楚：

问题一：能否在一个应用用shmat()，另一个用shm_open()实现内存共享？ #

答案是绝对不行，核心原因是这两套API的底层实现和标识体系完全不兼容：

• SysV共享内存属于System V IPC范畴，它通过ftok()生成的键值（key）或者IPC_PRIVATE来标识内存块，内核用独立的IPC对象管理器来维护这些内存，和文件系统毫无关联。shmat()是把这个内核IPC对象映射到进程的地址空间。
• POSIX共享内存则是基于文件系统的，它会在/dev/shm（tmpfs挂载的临时文件系统）下创建一个真实的文件节点，shm_open()本质就是打开这个特殊文件，后续通过mmap()完成内存映射。

简单说，这俩就像两个完全独立的内存池：一个用内部IPC编号管理，一个用文件路径定位，根本找不到对方的内存块，自然没法交叉实现共享。

问题二：用shm_open()和shmget()能否安全实现内存共享？ #

同样不行，而且这个问题的本质比第一个更严重——不光是找不到对应内存块，就算你强行想办法绕开标识问题（比如硬编码内存地址，这本身就极不可靠），两者的内存管理模型也完全不匹配：

• SysV共享内存的生命周期绑定内核IPC对象，只有调用shmctl(..., IPC_RMID, ...)或者系统重启时，内存块才会被释放。
• POSIX共享内存的生命周期绑定文件系统节点，shm_unlink()会删除节点，但只要还有进程映射着这块内存，它就会一直存在到最后一个进程解除映射。

除此之外，两套API的权限控制、命名空间、内存分配机制都存在差异，强行跨API访问要么直接报错（比如shmget()找不到对应键的IPC对象，shm_open()找不到对应路径的文件），要么就算侥幸能访问到内存，也会因为缺乏统一的同步和管理机制，导致数据损坏、进程崩溃甚至内核异常，完全谈不上“安全”。

总结 #

如果需要跨进程共享内存，必须统一使用一套API：要么全用SysV的shmget()/shmat()系列，要么全用POSIX的shm_open()/mmap()系列。交叉混用不仅实现不了需求，还容易引发各种问题。

内容的提问来源于stack exchange，提问作者Bruce Adams