共享内存这个东西第一次用很容易产生一种错觉不就是拿一块内存大家往里写吗能有多复杂。等到真把它放进一个多进程服务里发现数据读出来是乱的、进程崩了之后段还在、某台机器上跑得好好的换台机器就映射失败才开始意识到这块内存背后藏着的东西比想象中多。这篇内容围绕共享内存的三件事展开——映射、读写、控制把 System V 和 POSIX 两套接口的实际用法、参数含义、踩过的坑和排查思路都摊开讲。适合已经会写多进程程序、但还没把共享内存真正用稳的开发者也适合正在给现有系统做进程间通信选型的人。全程给的是能直接改成业务代码的骨架不讲教科书式的概念堆砌。1. 共享内存快在哪从一次数据搬运说起选共享内存的人多半是被最快这个说法吸引过来的。这个结论没错但如果不清楚它快在哪个环节就很容易在不该用的地方用它最后反而把系统搞复杂。1.1 管道和消息队列的时间花在了哪里进程之间默认是不共享地址空间的这是操作系统给的隔离保护。管道、消息队列、本地套接字这些机制本质都是让数据先从发送进程的用户空间拷进内核缓冲区内核再拷到接收进程的用户空间。一次传递两次拷贝外加系统调用进出内核的开销。数据量小的时候这些开销无所谓一条几百字节的控制消息拷贝两次也就几十纳秒的级别。但一旦碰上每帧几 MB 的图像数据、每秒几十万条的行情推送拷贝成本就会变成整个链路的主要瓶颈。我做过一个粗略的对比单条 1 MB 的数据走本地套接字回环往返一次大概在毫秒级换成共享内存只做一次写一次读量级直接掉到微秒以下。差距不是一点点。1.2 页表映射共享内存在内核里到底共享了什么共享内存的做法是把同一个物理内存页映射进多个进程各自的虚拟地址空间。每个进程看到的地址不一样但底下指向的是同一批物理页。写入的时候直接写物理内存不存在拷给别人这个动作。这里有个容易被误解的点共享内存并不是一块所有人都能访问的内存而是一块通过页表让多个进程都能看到的物理内存。这个区别决定了后续很多事情比如为什么进程退出后段还留着、为什么不同进程拿到的指针地址不同、为什么必须自己同步。内核在做shmat或者mmap的时候只是修改了调用进程的页表项让某个虚拟地址区间指向已经存在的物理页。这个动作本身很轻所以映射的建立和解除都很快。1.3 省掉的拷贝换来了什么责任省掉两次拷贝的代价是同步责任完全转移给了使用者。管道和消息队列自带边界语义写一次读一次内核帮你保证原子性和顺序。共享内存什么都没有它就是一块裸内存两个进程同时写同一个位置结果就是未定义的。所以真正决定共享内存方案成败的从来不是会不会用 shmat而是能不能设计出一套不出错的同步协议。这一点在后面第 5 章会详细展开这里先记住一个原则凡是共享内存必定配套一个同步机制没有例外。2. 映射的完整链路从 key 到可用指针映射是共享内存使用的第一步也是坑最集中的一步。很多人卡在这里不是因为接口不会调而是因为 key 的选取、权限位、返回值判断这些细节没弄明白。2.1 key 的生成ftok 的隐藏约束System V 共享内存靠一个key_t类型的键来标识。同一台机器上两个进程只要拿到相同的 key就能访问到同一个段。生成 key 常见两种做法写死一个常量或者用ftok从路径名 项目 ID推算。ftok的实现逻辑大致是把文件的 inode 号和设备号揉进 key 里所以它有两个硬性约束路径对应的文件必须真实存在而且inode 号不能被复用。我踩过一次坑清理脚本把一个临时文件删了又重建inode 变了ftok算出来的 key 跟着变结果两个进程各自创建了一个段互相看不见对方的数据排查了大半天。还有一个更隐蔽的问题ftok只取 inode 的低 16 位和设备的低 8 位文件系统里文件多了之后不同文件撞出同一个 key 是可能的。所以我的建议是生产环境直接用固定常量 key把它当成配置项管理比ftok可控得多。ftok适合 demo 和一次性脚本不适合长期运行的服务。2.2 shmget 的三个参数和权限位的真实含义shmget的签名是int shmget(key_t key, size_t size, int shmflg)。三个参数各有讲究。size这个参数有个特性如果段已存在传的 size 小于实际大小调用仍然成功但返回的是原有段。也就是说你不能靠传一个大 size 来扩容已有的段。想改大小只能删了重建或者在设计阶段就留足余量。shmflg里最关键的是IPC_CREAT和IPC_EXCL的组合。单独用IPC_CREAT段存在就返回已有的不存在就创建这是幂等初始化的写法服务启动时用它比较合适。加上IPC_EXCL就变成不存在才创建存在就报 EEXIST适合需要严格区分首次初始化的场景。权限位容易被忽略。0660表示属主和同组可读写其他用户无权限。这里有个细节创建时的权限位只在段首次创建时生效后续调用传的权限位会被忽略想改必须走shmctl的IPC_SET。标志组合段存在时行为段不存在时行为典型用途IPC_CREAT返回已有段 ID创建新段服务启动时幂等初始化IPC_CREAT | IPC_EXCL返回 -1errnoEEXIST创建新段判断是否为首次启动不带 CREAT返回已有段 ID返回 -1errnoENOENT客户端只连接不创建IPC_PRIVATE必然创建新段必然创建新段父子进程间传递无需 keyIPC_PRIVATE这个特殊 key 值得单独说一句。它的值是 0用它调用shmget每次都会创建一个全新段。因为拿不到固定 key其他无关进程没法直接访问只能通过fork继承或者把返回的 shmid 通过其他通道比如管道传出去。这种用法在父子进程协作的场景里非常干净避免了 key 冲突问题。2.3 shmat 的返回值判断一个经典到不能再经典的坑void *shmat(int shmid, const void *shmaddr, int shmflg)。失败时返回(void *)-1不是 NULL。这个坑几乎每个初学的人都会掉一次代码写成if (addr NULL)然后崩溃时完全找不到线索。shmaddr参数绝大多数情况传NULL让内核自己挑一个合适的地址。手动指定地址只在对齐有严格要求比如要映射到特定的巨大页边界时才用普通业务代码没必要碰指定错了还可能和已有的映射冲突。shmflg里常看的是SHM_RDONLY表示只读映射。这个在只读订阅场景下有用即使代码里误写也会直接触发段错误比读到脏数据好排查。另外SHM_RND用于地址对齐只在你手动指定shmaddr时才有意义。2.4 一个能跑起来的最小映射骨架下面这段代码是映射部分最精简的形态可编译可运行输出的段 ID 和挂接地址可以直接拿去对照ipcs的输出核对。#include stdio.h #include string.h #include errno.h #include sys/ipc.h #include sys/shm.h #define SHM_KEY 0x5A5A0101 #define SHM_BYTES (4 * 1024 * 1024) int main(void) { int shmid shmget(SHM_KEY, SHM_BYTES, IPC_CREAT | 0660); if (shmid -1) { fprintf(stderr, shmget failed: %s\n, strerror(errno)); return 1; } void *addr shmat(shmid, NULL, 0); if (addr (void *)-1) { /* 注意判断 -1不是 NULL */ fprintf(stderr, shmat failed: %s\n, strerror(errno)); return 1; } memset(addr, 0, SHM_BYTES); /* 首次初始化务必清零 */ printf(shmid%d addr%p size%d\n, shmid, addr, SHM_BYTES); if (shmdt(addr) -1) { fprintf(stderr, shmdt failed: %s\n, strerror(errno)); } return 0; }这段代码里有两件事必须注意。第一memset清零不能省。新创建的共享内存段内核不保证是零虽然实践中多数时候拿到的是全零页但绝不能依赖这个行为尤其当段是被复用的旧段时里面可能塞满上一个进程留下的数据。第二这个程序退出时只做了shmdt段还留在系统里需要额外执行ipcrm -m shmid清理这一点在第 4 章会详细说。3. 读写共享内存布局设计比拷贝动作重要得多映射拿到指针之后读写本身很简单memcpy就能搞定。真正容易出事的是数据在内存里的组织形式以及多个进程读写时的时序问题。3.1 结构体共享的三条硬规则跨进程共享结构体第一条规则是只用固定宽度类型。int、long、size_t这些类型的宽度跟平台和编译选项有关64 位和 32 位混跑、或者两个程序用不同的编译参数布局就会错位。应该统一用uint32_t、uint64_t、int8_t这类明确宽度。第二条规则是显式对齐。编译器会在结构体成员之间插入填充字节填充规则受#pragma pack、-fpack-struct等选项影响。最稳妥的做法是在结构体定义后面加一行_Static_assert把预期大小钉死#include stdint.h #include stddef.h typedef struct { uint32_t magic; /* 魔数用来快速校验段是否被正确初始化 */ uint32_t version; /* 结构体版本方便未来演进 */ uint64_t write_seq; /* 写入序号单调递增 */ uint32_t data_len; /* 有效数据长度 */ uint32_t flags; uint8_t payload[1024]; } shm_header_t; _Static_assert(sizeof(shm_header_t) 1048, shm_header_t layout mismatch); _Static_assert(offsetof(shm_header_t, payload) 24, payload offset mismatch);这两行断言看着啰嗦但它是唯一能在编译期发现布局漂移的手段。我在一个项目里就是因为两端程序一个用-O2一个用-O0加上不同的 pack 设置结构体差了 4 个字节导致data_len读出来的值永远是个离谱的大数查了很久才发现问题出在编译选项上。第三条规则是加上 magic 和 version 字段。共享内存段可能被复用的旧段、可能被上一个进程写过一半、可能被手工清空过读写之前先用 magic 校验一下能挡掉大量莫名其妙的错误。version 字段则为后续结构体演进留了口子——发现版本不匹配就重建段比兼容老布局省事得多。3.2 变长数据环形缓冲区加长度字段固定大小的结构体只够传控制信息。传变长数据比如消息流、帧数据得在共享内存里自己实现缓冲区管理环形队列是最常用的一种。设计要点在于读写位置和有效数据长度必须分开管理。常见做法是维护 head写位置、tail读位置两个偏移量再加一个计数器记录当前积压的数据量。判断空和满不能用head tail这一套因为环形队列满和空在指针上看起来是一样的。要么额外维护一个count字段要么永远浪费一个槽位。typedef struct { uint32_t magic; uint32_t capacity; /* 槽位总数 */ uint64_t head; /* 生产者写入位置 */ uint64_t tail; /* 消费者读取位置 */ uint64_t count; /* 当前已用槽位数 */ /* 之后紧跟 capacity 个定长槽位 */ } ring_ctrl_t; static inline uint32_t ring_next(uint64_t idx, uint32_t cap) { return (uint32_t)((idx 1) % cap); }count字段的更新必须在临界区里做因为它和 head/tail 之间要保持一致性。后面第 5 章会讲具体的同步手段。3.3 内存可见性编译器优化带来的隐蔽问题单核时代这个问题几乎不存在多核之后就变成了真实威胁。编译器可能在寄存器里缓存变量的值CPU 也可能乱序执行导致生产者明明先写了数据再更新 head消费者却看到了新的 head 和旧的数据。解决手段是内存屏障。用 GCC 内建函数比较简单/* 生产者先写数据再更新 head */ memcpy(slot, src, len); __atomic_store_n(ring-count, new_count, __ATOMIC_RELEASE); /* 消费者先读 count再读数据 */ uint64_t c __atomic_load_n(ring-count, __ATOMIC_ACQUIRE); memcpy(dst, slot, len);__ATOMIC_RELEASE保证它之前的写操作对其他线程可见__ATOMIC_ACQUIRE保证它之后的读操作能看到对应的写。这一对语义在无锁队列里是标准配置少了任何一个都可能在高负载下出现数据偶尔错乱这种极难复现的问题。我遇到过一次特别典型的本地开发机上跑压力测试三天三夜没问题上了多路服务器之后每隔几小时就有一条消息内容对不上。最后定位到就是生产者写完数据后直接更新了计数缺了 release 语义CPU 重排把顺序调换了。加上屏障之后再没出现过。3.4 读写操作的完整流程把上面几点串起来一个完整的写操作流程大致是这样先用信号量或者原子操作抢锁检查剩余空间是否够用不够就按业务策略处理丢弃、等待或覆盖最老的然后写数据到对应槽位更新计数和写指针最后释放锁。读操作对称抢锁检查是否有数据有就拷出来更新读指针释放锁。这里有个经验拷贝动作尽量放在锁外面。理想的写法是锁内只做指针移动和计数更新锁外做实际的数据 memcpy。因为锁的持有时间直接决定了并发度而 memcpy 大块数据的耗时可能远超过指针操作。做法是锁内先占位记下要写的槽位索引解锁后再往那个槽位里填数据。当然这要求槽位在填写期间不会被别人覆盖需要额外的状态位配合复杂度会上去一些。数据量小于几十 KB 的时候不值得这么折腾直接锁内拷贝就够了。4. 控制和生命周期shmctl 管得了什么、管不了什么共享内存最让人头疼的往往不是读写而是这个段到底还在不在、被谁占着、为什么删不掉。这部分全靠shmctl和几个系统工具配合。4.1 IPC_STAT从统计信息反推段的真实状态shmctl(shmid, IPC_STAT, buf)会把段的状态填进struct shmid_ds。这里面几个字段特别有用字段含义排查价值shm_segsz段大小字节确认创建时的 size 是否和预期一致shm_nattch当前挂接的进程数判断还有没有进程在用能否安全删除shm_cpid创建者的 PID定位是哪个进程创建的段shm_lpid最后一次操作者的 PID定位最后一次 attach/detach 来自谁shm_atime最后一次 attach 时间判断段是否还在被活跃使用shm_dtime最后一次 detach 时间配合 atime 判断使用模式shm_ctime最后一次状态变更时间追踪权限或状态修改历史实际排查中最常看的是shm_nattch。这个值是 0 说明当前没有任何进程挂着理论上可以安全删除。但注意它只是一个瞬时快照读完到你去删之间可能有新进程挂上来所以删除前最好先停掉所有可能访问的进程。shm_cpid在定位谁创建了这个野段时非常有用。有次线上机器上堆了几十个共享内存段不知道哪些是当前服务用的哪些是历史遗留就是靠shm_cpid对照进程列表逐个确认的。4.2 IPC_RMID 的真实语义标记删除而非立即释放这是共享内存生命周期里最容易误解的一点。调用shmctl(shmid, IPC_RMID, NULL)之后段并不会立刻消失。内核做的事情是给这个段打上删除标记从此新的 attach 请求会被拒绝返回 EIDRM但已经挂在上面的进程不受影响它们手里的指针依然有效依然能读写。真正的物理释放发生在最后一个进程执行shmdt之后。这个设计其实很合理避免了正在使用的进程突然访问到已释放的内存。但它带来的副作用是如果某个进程挂着段不 detach 就长期不退出段就一直占着内存不放。还有一种更隐蔽的情况进程崩溃了。正常情况下进程退出时内核会清理它的所有映射shm_nattch会自动减一。但如果段是被IPC_RMID标记过、且崩溃进程是最后一个持有者内核会在清理时把段彻底释放掉。所以崩溃后段还留着通常意味着还有别的进程挂着它。4.3 主动清理脚本化比手工稳开发阶段最烦的就是留下一堆不知道干嘛的段。手工ipcrm效率低还容易删错。我的做法是写一个清理脚本按创建者的进程名和段的创建时间来筛选。#!/bin/bash # 列出所有共享内存段及其创建者 for id in $(ipcs -m | awk /^0x/ {print $2}); do info$(ipcs -m -i $id) nattch$(echo $info | awk /nattch/ {print $NF}) cpid$(echo $info | awk /cpid/ {print $NF}) pname$(ps -p $cpid -o comm 2/dev/null) echo shmid$id nattch$nattch cpid$cpid comm${pname:-gone} done这个脚本的输出比单纯ipcs -m直观得多能直接看到哪个进程创建了哪个段。确认可以删的段用ipcrm -m shmid清掉。注意ipcrm只是发起删除请求含义和IPC_RMID一样如果还有进程挂着段会进入待删除状态而不是立刻消失。在 Linux 上还有个更底层的入口/proc/sysvipc/shm里面是内核维护的原始数据字段顺序固定适合脚本直接解析。相比ipcs的输出更稳定不受版本格式变化影响。4.4 IPC_SET 与权限边界IPC_SET主要用来改权限位和属主。用法上要注意权限位只对未来新挂接的进程生效已经挂上的进程不受影响。所以想撤销某个进程的访问权光改权限没用得把它的映射断掉。另外IPC_SET需要足够的权限才能调非属主或者没有相应能力的进程会失败。多用户环境下设计共享内存方案时这一点必须在部署阶段规划好别等到上线才发现某个服务的运行账户没权限挂载。5. 同步机制共享内存之外必须补上的那一块前面反复强调共享内存不带同步。这一章把几种常用的同步手段讲清楚包括它们各自适用的场景和容易出问题的地方。5.1 System V 信号量老派但可靠用 System V 信号量保护共享内存是最经典的组合拳。semget创建信号量集合semop做 P/V 操作。优势是内核原生支持进程间天然共享劣势是接口笨重出错时的错误码也比较难读。#include sys/sem.h union semun { int val; struct semid_ds *buf; unsigned short *array; }; static int sem_p(int semid, int idx) { struct sembuf op { .sem_num idx, .sem_op -1, .sem_flg SEM_UNDO }; return semop(semid, op, 1); } static int sem_v(int semid, int idx) { struct sembuf op { .sem_num idx, .sem_op 1, .sem_flg SEM_UNDO }; return semop(semid, op, 1); }SEM_UNDO这个标志值得单独提一句。它让内核记录进程对信号量做的操作进程异常退出时自动回滚。没有它的话一个进程拿了锁之后崩溃锁就永远锁住了。所有涉及可能崩溃场景的信号量操作都应该带SEM_UNDO这是低成本高收益的一行。5.2 POSIX 进程共享互斥锁更符合直觉的选择如果段里需要保护的临界区比较复杂比如嵌套结构、需要条件变量配合用 POSIX 互斥锁比信号量好写得多。关键是把互斥锁的变量本身也放在共享内存里并且初始化时设置PTHREAD_PROCESS_SHARED。#include pthread.h static int init_shared_mutex(pthread_mutex_t *m) { pthread_mutexattr_t attr; if (pthread_mutexattr_init(attr) ! 0) return -1; /* 关键让互斥锁可跨进程使用 */ if (pthread_mutexattr_setpshared(attr, PTHREAD_PROCESS_SHARED) ! 0) { pthread_mutexattr_destroy(attr); return -1; } /* 关键进程崩溃后锁能被接管而不是永久死锁 */ pthread_mutexattr_setrobust(attr, PTHREAD_MUTEX_ROBUST); int rc pthread_mutex_init(m, attr); pthread_mutexattr_destroy(attr); return rc; }这里有两个必须设置的点少一个都会出问题。PTHREAD_PROCESS_SHARED不设的话互斥锁只在进程内有效跨进程加锁完全不起作用——这种情况特别隐蔽因为程序不报错就是偶尔数据错乱。PTHREAD_MUTEX_ROBUST则是应对崩溃持锁进程挂掉后其他进程的pthread_mutex_lock会返回EOWNERDEAD需要调用pthread_mutex_consistent把锁恢复成正常状态然后重新保护数据一致性。拿到EOWNERDEAD之后的处理逻辑不能省。此时被保护的数据可能正处于写到一半的状态稳妥的做法是把整个数据结构重建一次而不是假装什么都没发生接着用。5.3 无锁方案在这个场景守不守得住理论上单生产者单消费者的环形队列可以做到完全无锁靠原子操作和内存屏障维护顺序。实测下来性能确实漂亮比加锁版本快一个数量级。但这个方案有严格前提生产者只能有一个消费者只能有一个。多生产者场景下多个进程同时 CAS 抢同一个位置失败重试的竞争开销会迅速吃掉无锁带来的收益甚至不如加锁。多消费者同理。还有一种情况也要避开槽位大小不固定。变长槽位的无锁队列实现复杂度陡增环形缓冲区要么按最大长度固定分配浪费空间要么引入复杂的内存管理收益根本不划算。我的判断标准是能明确保证单生产单消费、且数据量大于几十 KB 时值得上无锁其他所有情况老老实实用互斥锁。锁的实现在现代内核上已经很快了临界区够短的话争用成本完全可以接受。6. 排查实录段在、进程在、就是读不到数据讲一个真实碰到过的问题把排查链路完整走一遍。现象是主进程往共享内存里写数据工作进程读但工作进程偶尔会读到全零或者上一次的旧数据重启两边就正常跑一段时间又复发。6.1 从 ipcs 开始逐层确认第一步永远是确认段本身的状态。ipcs -m看段是否存在、大小对不对、nattch是多少。当时看到nattch是 3而预期只有主进程和工作进程两个多出来的那个是之前某次调试遗留的进程没退干净。顺着shm_cpid找到那个进程发现它老早就不该存在了只是被nohup挂住没死。它虽然不写数据但每轮循环都会读一次共享内存然后打印日志本身无害。但它的存在影响了后续判断先把它清掉nattch回到 2问题依旧。第二步看shm_lpid和shm_atime确认到底是哪个进程最后在做 attach。这一步排除了段被重复创建的可能因为两个进程的 PID 和预期一致。6.2 三个高频原因逐个排除到了这一步段和进程都没问题问题只可能在数据层面。按经验最常见的是三类。第一类是 key 冲突。两个不相关的服务用了同一个 key各自创建了段。因为shmget在段已存在时会直接返回已有的第二个服务根本不会报错直接拿到了别人的段。验证方法很简单把段内容 dump 出来看 magic 字段对不对如果 magic 完全不符合预期基本就是拿错段了。这次排查 magic 是对的排除。第二类是结构体布局不一致。两个程序编译参数不同或者头文件版本不同步导致结构体成员偏移对不上。这次的验证方法是让两个进程各自打印sizeof(struct)和关键成员的 offset对比一下。结果两边一致排除。第三类是同步缺失或错位。也是这次真正的原因。翻代码发现写进程在填完数据之后更新了一个ready标志读进程轮询这个标志。但写进程是先更新ready再 memcpy 数据——顺序反了。编译器还把ready的赋值提到了前面因为在那段代码里它看不出两者有依赖。改成先写完数据再更新标志并且给标志的写加__ATOMIC_RELEASE、读加__ATOMIC_ACQUIRE问题彻底消失。这个案例很典型共享内存上的并发 bug 往往不是锁用错了而是根本没有锁同时顺序还不对。6.3 崩溃后的清理顺序排查完之后还得清理现场。顺序很重要先停掉所有可能访问这个段的进程等待它们自然退出内核会逐个 detach确认nattch归零之后再执行ipcrm -m。反过来做先ipcrm再停进程段会进入待删除状态但迟迟不释放因为还有进程挂着。这时候ipcs里能看到段还在容易误以为删除失败又执行一遍实际上内核已经标记了再执行也不会更快。如果遇到某个进程挂死不动、kill -9也没反应的极端情况那基本只能靠重启来彻底隔离了。这也是为什么我建议在设计阶段就给共享内存段加一个明确的生命周期管理者由主进程负责创建和最终销毁工作进程只 attach 不负责清理避免职责分散导致谁都不敢删。7. POSIX 方案shm_open 配合 mmap 的那一套System V 那套接口年头久接口风格和现代系统编程有点脱节。POSIX 提供了一套基于文件描述符的方案用起来更顺手在新项目里我更推荐它。7.1 名字空间与持久性shm_open的第一个参数是一个名字形如/my_shm_name。这个名字在系统里映射到/dev/shm/目录下一个真实存在的文件节点可以直接用ls /dev/shm看到。这一点和 System V 的 key 差异很大名字是字符串可读性好不会有 key 冲突时悄悄拿到别人的段这种问题。用法上shm_open拿到 fd 之后先ftruncate设定大小再mmap映射最后正常读写指针。流程如下#include fcntl.h #include sys/mman.h #include sys/stat.h #include unistd.h #define SHM_NAME /demo_buffer #define SHM_SIZE (8UL * 1024 * 1024) void *posix_shm_map(void) { int fd shm_open(SHM_NAME, O_CREAT | O_RDWR, 0660); if (fd -1) return NULL; if (ftruncate(fd, SHM_SIZE) -1) { close(fd); return NULL; } void *addr mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); close(fd); /* mmap 之后 fd 可以关掉映射仍然有效 */ if (addr MAP_FAILED) return NULL; return addr; }两个细节值得注意。ftruncate这一步不能省shm_open创建出来的对象初始大小是 0不设定大小直接 mmap 会拿到SIGBUS。close(fd)放在mmap之后没问题映射和 fd 的生命周期是解耦的关掉 fd 映射依然有效。持久性方面POSIX 共享内存对象和文件一样进程退出后对象还在需要显式shm_unlink才会消失。这个语义比 System V 的IPC_RMID更直观和文件删除的习惯一致。7.2 两种方案怎么选对比项System VshmgetPOSIXshm_open mmap标识方式key_t整数字符串名字冲突风险高key 空间小低名字可读且唯一性强生命周期IPC_RMID标记删除最后 detach 才释放shm_unlink类似文件删除语义大小调整不支持只能删了重建ftruncate可直接改可见性ipcs查看ls /dev/shm查看跨平台各 Unix 实现有差异标准化程度更高我的选择习惯是新项目、需要跨平台、需要直观管理一律用 POSIX维护老代码或者对端程序只实现了 System V 接口就迁就它。两套方案在性能上没有实质差别都是同一套页表映射机制差别全在接口和管理语义上。8. 容量、性能与几条实测心得最后聊几个偏工程层面的经验这些内容文档里基本不会写但真正决定方案好不好用。8.1 段大小不是越大越好创建共享内存段的时候size参数只是向内核申请虚拟地址空间物理内存是按需分配的只有真正访问到的页才会被分配。所以创建一个 1 GB 的段实际只写了几 MB 的数据物理内存占用也就几 MB。这个特性很容易被误解成创建大段会吃掉很多内存。但也不能无限放大。段的大小会影响shmget时内核的元数据开销而且虚拟地址空间的碎片化在极端情况下会带来问题。我的经验值是预留峰值用量的 1.5 倍超过 64 MB 的段考虑拆成多个用途独立的段。这样单个段出问题时影响范围可控也便于按用途分配不同的权限和同步策略。Linux 上还可以关注kernel.shmmax和kernel.shmall这两个内核参数它们限制了单个段的最大尺寸和系统总共享内存页数。容器环境下这两个值往往被调得很小部署前确认一遍能省掉不少为什么本地跑得好、容器里 shmget 报 ENOSPC的困惑。8.2 大页与内存访问模式数据量大、访问频繁的场景可以考虑用大页减少 TLB 缺失。System V 共享内存支持SHM_HUGETLB标志但需要系统预先配置好大页池申请失败会直接报错不具备回退能力用之前一定要测。更实用的优化往往不在页大小上而在访问模式上。尽量让每个进程只读自己关心的区域不要所有进程都遍历整个段。共享内存的物理页是共享的多个进程同时读同一页时缓存命中率很高但如果各自扫不同的区域缓存就会互相挤占。在数据结构布局上按谁用谁读分区比调任何内核参数都有效。8.3 一个务实的上线检查清单把前面所有内容收拢成一份上线前对照的表每次新接一个共享内存方案我都会过一遍检查项具体动作key / 名字唯一性固定常量并纳入配置管理不用ftok权限位按最小必要设置确认运行账户能挂载结构体布局全固定宽度类型 _Static_assert校验大小与偏移初始化首次创建后清零写入 magic 和 version同步每个可写区域都有明确归属锁或原子操作到位崩溃处理互斥锁设 robust信号量带SEM_UNDO生命周期指定唯一创建者与销毁者避免互相推诿容量预留 1.5 倍峰值确认内核参数限制监控定期采集nattch、段大小、异常残留段数量这份表里的最后一项经常被忽略。共享内存的问题大多是渐进式的——段慢慢泄漏、内存慢慢增长、某个进程偶尔挂着不走。主动监控这些指标比事后排查省太多力气。我个人在这些年的实操中最深的一点体会是共享内存的复杂度从来不在接口上shmget、shmat、shmctl三个函数半小时就能背下来。真正花时间的是围绕它的那套约定——数据怎么布局、谁来同步、段归谁管、崩了怎么恢复。这四个问题在动手写第一行代码之前就应该有答案写成文档让所有参与者对齐。等代码跑起来再补这些约定返工成本会高出一个量级。另一个小技巧是任何共享内存相关的代码第一次跑通之后立刻做一轮故意制造异常的测试——中途kill -9、把段填满、让两个进程同时抢写——暴露出的问题往往比正常路径多得多改起来也便宜。