POSIX共享内存通过shm_open创建/dev/shm下命名对象，ftruncate设大小，mmap映射读写；需同步机制（如原子类型或进程共享互斥量）避免竞态，shm_unlink异步清理。
Linux 下用 shm_open + mmap 创建可读写共享内存
共享内存不是“开个口子大家随便写”，而是先申请一段内核管理的内存页，再由各进程映射到自己地址空间。最稳妥的方式是 POSIX 共享内存（shm_open），它比 System V 的 shmget 更现代、路径可控、权限明确。
关键步骤：调用 shm_open 创建或打开一个带名字的共享内存对象（类似文件路径，但存在 /dev/shm 下），用 ftruncate 设定大小，再用 mmap 映射进进程地址空间。
-
shm_open的 flag 必须包含O_RDWR，否则mmap会失败（即使只读也要设为可读写，映射时再控制prot） - 名字必须以
/开头，如"/my_shm"；不能含其他斜杠，也不能是绝对路径（shm_open("/tmp/my", ...)会报ENAMETOOLONG） - 映射后记得
munmap，但closefd 不影响映射，真正释放要靠shm_unlink（且需所有进程都 unmapped 后才真正销毁）
int fd = shm_open("/my_shm", O_CREAT | O_RDWR, 0644);
ftruncate(fd, 4096);
void* ptr = mmap(nullptr, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
// 使用 ptr 读写...
munmap(ptr, 4096);
close(fd); // 可晚些再 close
// 最后由某一方调用：
shm_unlink("/my_shm"); // 注意：不是 unlink("/dev/shm/my_shm")
为什么直接写共享内存会出错：缺少同步机制
共享内存本身不提供任何并发保护。两个进程同时往同一块 int* 写，大概率得到错误值——这不是 C++ 问题，是 CPU 缓存、编译器重排、指令乱序共同导致的。
不能靠 volatile 解决，它只禁用编译器优化，对 CPU 缓存和多核可见性无效。
立即学习“C++免费学习笔记（深入）”；
- 简单场景用
pthread_mutex_t：把互斥量也放在共享内存里（需用PTHREAD_PROCESS_SHARED初始化） - 更轻量可用
std::atomic类型（如std::atomic_int），前提是它们在共享内存中正确对齐，且目标平台支持无锁原子操作（x86-64 通常 OK） - 避免用
std::mutex：它的内部实现依赖线程私有数据，无法跨进程生效
Windows 上对应方案是 CreateFileMapping + MapViewOfFile
Windows 没有 shm_open，但语义等价的是内存映射文件（哪怕不关联磁盘文件）。关键区别在于命名和安全属性。
- 名称传给
CreateFileMapping，如L"Local\MySharedMem"（Local\表示当前会话，避免权限问题；不用Global\除非真需要跨会话） -
dwMaximumSizeHigh和dwMaximumSizeLow合起来指定大小（32 位系统需拆分） -
MapViewOfFile返回的指针可直接读写，但必须用UnmapViewOfFile+CloseHandle配对清理 - 没有类似
shm_unlink的自动清理机制：最后一个CloseHandle就释放，但若进程崩溃未关闭句柄，内存会残留（需手动用工具或重启清理）
跨平台封装要注意的三个硬伤
别幻想一个类搞定所有平台。实际项目中，以下三点最容易漏掉：
- 共享内存对象的生命周期管理：Linux 下
shm_unlink是异步的，可能被其他进程重建同名对象；Windows 下名称冲突更隐蔽（大小写敏感与否取决于系统配置） - 结构体布局必须显式对齐：
#pragma pack(1)或alignas，否则不同编译器/平台下成员偏移不同，读出来就是乱码 - 字符串不能存裸指针：
char*在共享内存里毫无意义，必须存完整缓冲区或用固定长度数组（如char name[64]）
共享内存快，但“快”只体现在数据拷贝环节；同步、序列化、生命周期这三件事，往往比通信本身更耗神。
