共享内存是linux下c++多进程大数据通信唯一真正零拷贝、低延迟方案，需用shm_open（name以/开头）+ mmap（map_shared）+ ftruncate设大小+pod结构体+命名信号量同步，禁用std::string等非pod类型。

共享内存是 C++ 多进程间传递大数据唯一真正零拷贝、低延迟的方案，但直接用 raw mmap 或 shm_open 容易踩坑——比如数据覆盖、同步缺失、资源泄漏。关键不在“能不能传”，而在“怎么保证每次读写都安全且可预期”。

Linux 下用 POSIX 共享内存（shm_open + mmap）传大数据

这是最常用、跨发行版兼容性最好的方式，适合 1MB～数 GB 级别数据。核心不是把整个结构体 memcpy 进去，而是把共享内存当“裸地址池”，自己管理布局和生命周期。

• shm_open 的 name 必须以 / 开头（如 "/my_data"），否则在某些内核版本会失败
• 调用 ftruncate 设置大小前，必须确保 fd 有效；否则 mmap 可能成功但访问时触发 SIGBUS
• 映射时推荐用 MAP_SHARED（而非 MAP_PRIVATE），否则写操作不会反映到其他进程
• 大数据建议按固定块切分（如每块 64KB），配合 ring buffer 结构，避免单次写入阻塞太久

Windows 下用文件映射（CreateFileMappingA + MapViewOfFile）的注意事项

Windows 没有 shm_open，必须通过命名文件映射对象实现等效功能。名字冲突、权限、句柄泄露是高频问题。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 创建时 CreateFileMappingA 的 lpName 参数需全局唯一，建议拼接进程名或 PID 避免冲突
• 必须显式设置 PAGE_READWRITE 权限，否则 MapViewOfFile 返回 NULL
• 映射后一定要检查返回值是否为 INVALID_HANDLE_VALUE 或 NULL，Windows 错误码藏在 GetLastError() 里
• 多个进程同时映射同一对象时，UnmapViewOfFile 不影响其他进程，但 CloseHandle 后该对象仍存在，直到所有句柄关闭

为什么不能直接往共享内存里放 std::string 或 std::vector

因为这些容器内部指针指向的是各自进程的堆内存，不是共享区域。一写进去，另一端解引用就是野指针或段错误。

• 只允许存放 POD 类型（如 int、struct 仅含基本类型字段、char[] 数组）
• 若需字符串，用定长 char name[256]；若需动态长度，前面加一个 size_t len 字段，再跟原始字节
• 哈希表、链表等复杂结构必须手写内存布局，或改用 lock-free ring buffer + 偏移量索引
• 想封装成类？必须禁用默认构造/拷贝/移动，所有成员变量地址都基于共享基址计算（即“placement new” + 手动 offset）

同步机制选型：信号量 vs 自旋锁 vs 无锁原子操作

大数据传输本身不慢，慢在等待对方就绪。选错同步方式会让吞吐量断崖下跌。

• 跨进程必须用命名信号量（sem_open / CreateSemaphoreA），匿名信号量只在同进程线程间有效
• 如果数据写入频率 > 10kHz，慎用信号量——系统调用开销大，改用共享内存内嵌的 std::atomic_flag（需保证对齐和缓存一致性）
• 生产者-消费者模型强烈推荐环形缓冲区（ring buffer），用两个原子整数分别记录 head 和 tail，避免锁竞争
• 注意：x86 上 std::atomic 默认带 memory_order_seq_cst，性能略低；高吞吐场景可用 memory_order_acquire/memory_order_release 配对

真正难的不是映射那几行代码，而是让两个独立进程对“此刻内存里哪部分可读、哪部分正被写、哪部分已过期”达成一致。这个一致性的维护成本，往往比数据搬运本身高一个数量级。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！