优先使用 shm_open 而非 mmap + shm_unlink；它自动管理命名空间与生命周期，支持 O_EXCL 防竞态、fcntl 加锁，并需配 O_CREAT | O_RDWR、ftruncate 设大小、显式内存对齐及 atomic 的 acquire-release 内存序。
共享内存选 shm_open 还是 mmap + shm_unlink？
直接用 shm_open，别自己拼 mmap + 文件路径。高频交易场景下，shm_open 返回的 fd 可直接 mmap，且能被 fcntl 加锁、支持 O_EXCL 防重复创建——这点对多进程竞态初始化至关重要。手写临时文件路径（比如 /dev/shm/mybook_123）容易撞名或权限失败，shm_open 自动处理命名空间和生命周期。
常见错误现象：shm_open: No such file or directory —— 多半是没加 O_CREAT；Permission denied —— 忘了 chmod 或 umask 拦截了写权限。
- 必须用
O_RDWR | O_CREAT，加O_EXCL做首次创建保护 -
shm_open后立刻调ftruncate设定大小，否则mmap会失败 - 避免用
MAP_SHARED | MAP_ANONYMOUS：它不落地、不跨进程，只适合单进程线程间共享
结构体布局必须显式对齐，否则读写错位
不同进程编译器可能对同一 struct 打包规则不一致，尤其在 x86_64 和 ARM64 混合部署时。高频交易里一个字段偏移错 1 字节，就可能把价格当时间戳解析，后果是下单发错价。
使用场景：订单簿快照、逐笔成交、风控阈值配置——所有需要零拷贝直读的结构体。
立即学习“C++免费学习笔记（深入）”；
- 每个字段前加
alignas(8)，整体 struct 末尾补static_assert(sizeof(MyStruct) == 128, "size mismatch") - 禁用
#pragma pack：它不可移植，GCC/Clang/MSVC 行为不一致 - 禁止用
std::string或指针成员：共享内存里地址无效，改用固定长数组 +uint16_t len
如何避免读写撕裂？别依赖 std::atomic 的默认内存序
std::atomic<uint64_t> 在 x86_64 上虽天然原子，但默认 memory_order_seq_cst 会插入 mfence，吞吐掉 5%～10%。高频通信要求写入即刻可见、读取不阻塞，得降级到 memory_order_acquire/memory_order_release。
典型错误：data->seq.store(++local_seq) 用了 relaxed，导致消费者看到新数据但没看到配套的校验和字段。
- 生产者写完数据块后，用
store(release)更新一个std::atomic_uint32_t version - 消费者先
load(acquire)version，再读数据——CPU 和编译器都不会重排这个顺序 - 禁用
memory_order_consume：实际优化效果差，且 GCC 已标记为 deprecated
进程崩溃后共享内存残留怎么清理？
不能靠 atexit 或 RAII：进程被 kill -9 时根本不会触发。高频系统常驻运行，一次残留就卡死后续启动。
正确做法是用「带锁的命名信号量」配合共享内存，由首个进程创建，最后一个退出时销毁。
- 用
sem_open("/mybook_sem", O_CREAT, 0644, 1)创建命名信号量 - 每次打开共享内存前，
sem_wait一次；关闭后sem_post一次 - 主进程启动时尝试
sem_getvalue，若为 0 说明上次异常退出，调shm_unlink+sem_unlink强制清理
容易被忽略的是：Linux 的 /dev/shm 默认大小只有 64MB，大订单簿或深度行情容易填满，得提前 mount -o remount,size=2G /dev/shm。还有，shm_unlink 不等于立即释放内存，得等所有进程 munmap 后才真正回收。
