Linux共享内存实战：原理、API对比与常见坑排查

1. 共享内存到底解决了什么问题

先聊点实在的。写过并发程序的人应该都有这种体会：两个进程要交换数据，翻来覆去就那么几条路——管道、消息队列、Socket。管道用起来简单，但本质是内核帮忙拷贝数据，一进一出两次复制，数据量大一点延迟就上来了。消息队列则是按消息块传递，适合小数据量，搞个几百KB的大块头照样吃力。Socket就更不用说了，跨网络通信没问题，本机两个进程互传数据拿它来用，属于杀鸡用牛刀，而且性能损耗一点没少。

共享内存的思路完全不一样：干脆把一块物理内存映射到多个进程的虚拟地址空间里，大家直接读写同一块内存。数据放进去，另一个进程马上就能看到，中间不需要内核参与搬运。这就相当于几个人共用一个白板，谁想写就写，谁想读就读，而不是像管道那样，A写一封信塞进邮筒，邮递员（内核）再送到B手里。

这套方案能给性能带来质的提升，原因很简单：省掉了两次数据拷贝。管道和消息队列传输数据时，数据先从用户态拷贝到内核态，再从内核态拷贝到另一个进程的用户态，两次拷贝都是实打实的CPU开销和内存带宽开销。共享内存呢？数据只用写一次到共享区域，读方直接访问同一块物理内存，零拷贝。实测下来，同样是传几十MB的数据，共享内存的吞吐能比管道高出好几倍，延迟更是低了一个数量级。

不过天下没有免费的午餐。共享内存最大的问题不是性能，而是同步。多个进程同时读写同一块内存，没有一套协调机制的话，数据错乱、读到半截数据都是家常便饭。所以共享内存几乎总得搭配信号量、互斥锁之类的同步手段一起用，包括Linux自带的POSIX信号量、System V信号量，或者自己用原子操作实现一个简单的自旋锁。

另外还有一个容易被新手忽视的点：共享内存的生命周期不跟随进程。管道、消息队列随着最后一个进程退出就销毁了，共享内存不是。它一旦创建，就一直在内核里挂着，除非你显式调用删除接口，或者重启机器。写服务端程序的人如果忘了在退出时清理共享内存，时间一长系统里就会积累一堆僵尸共享内存段，看着碍眼，还占着物理内存。后面我会专门讲这个问题。

这篇文章的内容，我会以Linux平台为主，围绕共享内存的两种主流实现——System V共享内存和POSIX共享内存来展开。先说底层原理和关键数据结构，再完整演示两个进程通过共享内存传递结构体数据的例子，最后把常见坑和排查手段整理成一份速查表。

2. 两类共享内存API，怎么选

2.1 System V共享内存：经典但啰嗦

System V共享内存是Unix老牌进程间通信手段，接口设计比较古早，但胜在稳定和普及。核心接口就三个：shmget创建或获取共享内存段，shmat把共享内存挂到当前进程的虚拟地址空间，shmdt卸载，还有一个shmctl负责控制操作，比如查询状态、标记删除。

创建一段共享内存的典型代码长这样：

int shmid = shmget(IPC_PRIVATE, 4096, IPC_CREAT | 0666); if (shmid == -1) { perror("shmget"); exit(EXIT_FAILURE); }

这里的第一个参数IPC_PRIVATE表示创建一个全新的共享内存段，相当于“私有”的、不和任何既有段关联。第二个参数是大小，单位是字节，系统会按页对齐，也就是说你申请4096字节，实际上可能占了一页（通常4KB）物理内存。第三个参数是权限标志，IPC_CREAT表示不存在就创建，0666是八进制权限位，跟文件权限一个意思，表示所有用户可读可写。

拿到shmid之后，把共享内存映射到当前进程的地址空间：

void *ptr = shmat(shmid, NULL, 0); if (ptr == (void *)-1) { perror("shmat"); exit(EXIT_FAILURE); }

shmat的第二个参数传NULL，让内核自己选一块合适的虚拟地址来映射，这是最省心的做法。第三个参数通常传0，不做特殊限制。

用完后或者进程退出前，要卸载映射：

shmdt(ptr);

注意，shmdt只是解除当前进程的映射关系，共享内存段本身还活着。要想彻底删除，得用shmctl：

shmctl(shmid, IPC_RMID, NULL);

但这里有个经典陷阱：如果在还有进程attach着这段共享内存的时候就调用IPC_RMID，会发生什么？在Linux上，删除标记会挂上，但共享内存不会被真正释放，直到所有进程都detach之后才彻底销毁。已经attach的进程还能继续读写，只是不能再有新的进程attach进来了。这个语义曾经坑过不少老手，后面排查环节我会专门说。

2.2 POSIX共享内存：更现代的替代品

POSIX共享内存是POSIX标准下的另一套API，设计风格比System V清爽不少，有点“文件操作”的味道。它把共享内存对象当作文件一样处理：shm_open打开或创建对象，ftruncate设置大小，mmap映射到进程地址空间，用完munmap，最后shm_unlink删除。

创建并映射的代码：

int fd = shm_open("/my_shared_mem", O_CREAT | O_RDWR, 0666); if (fd == -1) { perror("shm_open"); exit(EXIT_FAILURE); } ftruncate(fd, 4096); void *ptr = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (ptr == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); }

可以看到整体流程就是标准的文件操作加mmap映射。这里的"/my_shared_mem"是POSIX共享内存对象的名称，必须以斜杠开头，而且最大长度有限制，一般是NAME_MAX级别。对象实际存放在/dev/shm（tmpfs文件系统）上，这也意味着它是内存文件，重启就没了，跟System V段一样不持久化。

删除对象很简单，只要调shm_unlink传入名称，不需要等所有进程都解除映射。这一点和System V不同。但要注意，如果还有进程在mmap着这个对象，shm_unlink之后它们依然能正常访问，只是对象的名字从文件系统里消失了，新进程再想shm_open同一个名字会找不到。

2.3 两者对比，怎么选

我个人在实际项目中更倾向POSIX共享内存。原因有两个：第一，接口设计更贴近程序员日常的文件操作直觉，出错率低；第二，配合mmap可以用MAP_SHARED之外的一些高级特性，比如MAP_POPULATE预先映射物理页、MAP_LOCKED锁页防止被换出，这些都是System V的shmat不太好直接控制的。当然，如果你维护的是老代码，或者必须考虑非常老的Unix环境兼容性，System V依然是可靠选择。

3. 用共享内存传结构体，完整实操

3.1 场景设定与总体架构

现在进入实战环节。整个演示用两个进程：一个服务端（writer），一个客户端（reader）。服务端启动后创建一块共享内存，往里写入一个包含多条记录的结构体数组，然后通知客户端去读。客户端读取后打印并做简单校验，最后双方协调清理共享内存。

这里有个核心设计问题：进程之间怎么知道共享内存的标识？

如果是System V方式，进程A创建共享内存后得到shmid，进程B怎么拿到这个数字？最原始的办法是把shmid写进一个文件，或者通过命令行参数传过去。但更标准的做法是用ftok函数，通过一个文件路径加一个项目ID，生成一个固定的key，两个进程各自调用ftok拿到同样的key，再用这个key去shmget。这相当于共享内存的“暗号”——双方约定好同一个文件名和项目ID，就能定位到同一块内存。

POSIX共享内存就简单一些，双方约定好同一个对象名称字符串就行，比如"/my_shared_mem"。这个名称就是全局可见的，类似一个文件路径名，不会像shmid那样随机变化。

我这次演示用POSIX接口，因为流程更直观，而且和文件操作的习惯一致，便于扩展。

3.2 共享内存中应该如何组织数据

共享内存里存的往往不是单个变量，而是一结构体数组或者队列。但结构体里一旦有指针，事情就麻烦了：进程A的地址空间和进程B的地址空间完全不同，A写入的指针值B根本无法解引用。这是新手最容易踩的坑之一。

解决办法有两个：

第一，结构体里绝对不用指针，全部用定长数组或者值类型。比如要传一个字符串，不要用char *，而用char name[32]。

第二，如果必须要传变长数据，那就用偏移量代替指针。比如结构体里存一个int offset，指向数据在共享内存中的相对位置，接收方用基地址加偏移量来访问。这在实现共享内存环形队列或日志缓冲时非常常见。

我的演示结构体就按第一条来做，全部定长：

#define NAME_LEN 32 #define MAX_RECORDS 10 typedef struct { int id; char name[NAME_LEN]; double score; } Record; typedef struct { int count; Record records[MAX_RECORDS]; } SharedData;

这样整个SharedData的大小是固定的：count占4字节，records数组是10 * (4 + 32 + 8) = 440字节，总大小444字节，考虑对齐后是448字节左右。我申请共享内存时直接给了4096字节，完全够用，还留了余量以便以后扩展字段。

3.3 服务端完整实现与解析

服务端代码：

#include <fcntl.h> #include <sys/mman.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <semaphore.h> #define SHM_NAME "/demo_shm" #define SHM_SIZE 4096 typedef struct { int id; char name[32]; double score; } Record; typedef struct { int count; Record records[10]; } SharedData; int main() { int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666); if (fd == -1) { perror("shm_open"); exit(EXIT_FAILURE); } if (ftruncate(fd, SHM_SIZE) == -1) { perror("ftruncate"); exit(EXIT_FAILURE); } SharedData *data = mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (data == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } >#include <fcntl.h> #include <sys/mman.h> #include <sys/stat.h> #include <unistd.h> #include <stdio.h> #include <stdlib.h> #define SHM_NAME "/demo_shm" #define SHM_SIZE 4096 typedef struct { int id; char name[32]; double score; } Record; typedef struct { int count; Record records[10]; } SharedData; int main() { int fd = shm_open(SHM_NAME, O_RDWR, 0666); if (fd == -1) { perror("shm_open"); exit(EXIT_FAILURE); } SharedData *data = mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (data == MAP_FAILED) { perror("mmap"); exit(EXIT_FAILURE); } printf("count = %d\n",>sem_t *sem = sem_open("/demo_sem", O_CREAT, 0666, 0); if (sem == SEM_FAILED) { perror("sem_open"); exit(EXIT_FAILURE); } // 写入数据... // 写完所有数据后，发布信号量 sem_post(sem);

客户端添加：

sem_t *sem = sem_open("/demo_sem", 0); if (sem == SEM_FAILED) { perror("sem_open"); exit(EXIT_FAILURE); } // 等待服务端发信号 sem_wait(sem); // 读取共享内存...

这里信号量初始值为0，表示刚开始没有“可用资源”。服务端写完数据后sem_post把信号量加1，客户端sem_wait发现值大于0才继续执行，否则阻塞等待。这个模式在实际项目中是最基础的“就绪通知”模式。

如果需要两个进程反复交替读写同一块共享内存，那就得用两个信号量，一个表示“缓冲区空”，一个表示“缓冲区满”，这就是经典的生产者-消费者模型。比如生产者写完后post“满”信号量，消费者读完后post“空”信号量，双方交替等待。这种模式比单纯一个信号量更安全。

还有个更细的粒度问题：如果多个进程同时往共享内存的不同区域写数据，是不是就不需要加锁？不一定。有些CPU架构下，即使是不同地址的写入也可能因为缓存行（cache line）的竞争而互相拖慢，更不用说结构体里的字段如果落在同一个缓存行内，两个进程的写入会互相践踏。所以即便是分区写入，也最好让不同的写区域尽量分散到不同的缓存行。这个优化在低延迟场景非常重要。

3.6 编译与运行效果

两个程序分别编译：

gcc -o writer writer.c -lrt -lpthread gcc -o reader reader.c -lrt -lpthread

注意POSIX共享内存和POSIX信号量都要链接lrt（老版本glibc需要），信号量还要链接lpthread。现在较新的glibc（2.34之后）把lrt合并进了libc，不加也能编过，但为了兼容旧环境，建议还是保留。

先运行writer再运行reader：

./writer ./reader

reader输出：

count = 3 id=1 name=alpha score=88.50 id=2 name=beta score=92.00 id=3 name=gamma score=76.30

是不是很简单？但就是这层“简单”背后，隐藏着不少只可意会的坑。

4. 常见问题与排查技巧实录

4.1 共享内存没清理，系统里堆了一堆僵尸段

这是运维和开发都会遇到的经典问题。用System V共享内存的程序如果崩溃了或忘记shmctl删除，共享内存段就一直在内核里挂着。时间长了，用ipcs -m一看：

------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 32768 user 600 4096 0 0x00000000 32769 user 600 1048576 0 0x00000000 32770 user 600 65536 0

nattch为0说明没有进程attach，但段一直在。这种段占着内存不干正事，唯一的处理方式是手工清理：

ipcs -m | awk '{print $2}' | xargs -I {} ipcrm -m {}

注意生产环境操作前一定确认段归属，别把别的业务的共享内存也删了。

对POSIX共享内存来说，残留的对象会出现在/dev/shm下面：

ls -lh /dev/shm

对应的文件删掉即可：rm /dev/shm/xxx。但这里有个细节：如果还有进程正在mmap映射这个文件，直接rm之后，那个进程依然能正常访问，只有新进程再去shm_open同名对象才会失败。所以清理之前还是要确认没有活跃用户。

4.2 shm_open返回ENOENT或EACCES

ENOENT一般是客户端用了O_CREAT之外的标志去打开一个不存在的共享内存对象。EACCES则是权限问题。常见原因有两个：一是服务端创建对象时权限位设了0600，其他用户身份的进程访问不了；二是对象所在的/dev/shm挂载目录有特殊的挂载选项。

解决思路是创建时明确指定权限，比如0666，并确保服务端和客户端运行在同一个用户下，或者通过用户组来控制访问。另外，如果系统对/dev/shm有nosuid等挂载限制，可能会影响某些操作，排查时可以用mount命令看一下挂载参数。

4.3 mmap之后写入数据，另一个进程读不到

这个问题的原因九成是mmap时用了MAP_PRIVATE而不是MAP_SHARED。MAP_PRIVATE会做写时复制（Copy-on-Write），你往里写数据只是改了进程自己的副本，别的进程根本看不到。这在调试共享内存时特别容易踩。检查代码和编译输出，确保MAP_SHARED传进去了。

还有一个原因：mmap映射的大小超过了你ftruncate设置的大小。比如ftruncate只给了1024字节，你却mmap了4096字节，那超出1KB的部分访问结果是未定义的，可能触发SIGBUS信号导致进程崩溃。所以mmap的len参数必须小于等于ftruncate设置的size。

4.4 SIGBUS崩溃

SIGBUS，不是SIGSEGV，是总线错误，通常发生在访问mmap区域中尚未被文件或共享内存对象“支撑”的页面。举个例子：你ftruncate了512字节，但mmap了4096字节。访问前512字节没问题，一旦访问第513字节之后的任何地址，内核尝试从映射对象读取数据，发现对象大小不够，直接SIGBUS。

这在配置共享内存大小时是个隐蔽的坑。一定记住：mmap的映射长度永远不要超过ftruncate设置的长度。更好的做法是用一个宏把两者统一起来，避免手写数字不一致：

#define SHM_SIZE 4096 ftruncate(fd, SHM_SIZE); void *ptr = mmap(NULL, SHM_SIZE, ...);

4.5 结构体里有指针，跨进程直接崩

前面说过，共享内存里的指针不能直接跨进程使用。进程A往共享内存写入一个char *指向自己堆上的字符串，进程B拿到这个指针去访问，B自己的地址空间根本没有这段内存，直接段错误。

我自己踩过这类坑之后，形成了一个习惯：凡是要放进共享内存的结构体，一律只用定长数组。如果必须要变长数据，那就用相对偏移量。比如：

typedef struct { int data_offset; int data_len; char reserved[64]; } VariableRecord;

这里的data_offset是相对共享内存基地址的偏移，接收方拿到基地址加偏移就能定位数据。这个模式在实现日志缓冲区、共享内存环形队列时非常实用。

4.6 系统限制不够用

共享内存有系统级上限。Linux下几个关键参数：

如果在创建大块共享内存时失败，先看这几个值。临时调整可以用echo直接写，永久改要写/etc/sysctl.conf。比如：

sysctl -w kernel.shmmax=1073741824 echo "kernel.shmmax=1073741824" >> /etc/sysctl.conf

对POSIX共享内存，/dev/shm的大小还受tmpfs挂载参数影响，df -h /dev/shm看一下余量。临时扩大：

mount -o remount,size=2G /dev/shm

这个命令在大多数发行版上能直接生效，但重启后失效，要持久化还得改/etc/fstab里tmpfs那行。

4.7 多进程同时写，数据乱了

这个问题我在前面提到过，这里再展开。杀进程级数据错乱的本质是“读-改-写”不是原子的。比如两个进程同时执行：

data->count =>strace -f -e trace=shm_open,shm_unlink,mmap,ftruncate ./reader

如果shm_open返回-1，strace会直接显示错误码，比如ENOENT或EACCES，一眼就能看出是权限问题还是对象不存在。比在代码里加一堆printf排查高效得多。

5.3 用共享内存做性能验证的一个小心得

很多人验证共享内存性能时喜欢用单次大块拷贝来测，比如一次性拷贝128MB。这种测试并不能真实反应生产场景，因为大块拷贝的耗时主要被DMA和内存带宽卡住，共享内存和管道的差距反而没那么明显。

更贴近真实场景的测试是高频小数据交互，比如10字节一条消息，每秒发送几十万次。这种情况下共享内存零拷贝的优势会非常突出，因为每次通信都省去了两次内核拷贝和上下文切换的开销。我在这类测试中测过，共享内存比Unix域Socket快2到4倍，比TCP loopback快一个量级都不稀奇。

所以如果你在评估一个系统该不该用共享内存，先想清楚它的通信模式：高频小消息、大数据量低频率、还是高并发读写？共享内存在前两种模式下优势明显，在第三种模式里优势会被锁竞争抵消一部分，需要仔细设计分区和锁粒度。

6. 适合用共享内存的场景梳理

6.1 高频交易和实时数据处理系统

这类系统对延迟极其敏感，消息路径上每多一次拷贝、多一次系统调用都可能影响整体性能。共享内存作为进程间数据交换的“高速公路”，配合忙等待（spin-wait）或低开销信号量，可以把单次通信延迟压到微秒级。

常见的架构是：一个数据采集进程写共享内存，多个计算进程从共享内存读数据，各自处理不同维度。因为没有锁的话多读单写可以直接跑，比任何消息队列都省心。

6.2 图像帧或音视频流传输

摄像头采集程序拿到的帧数据通常是几个MB的原始YUV或RGB，如果走管道或Socket，每次传输都有两次拷贝，高帧率下CPU占用会非常难看。用共享内存加环形缓冲区（ring buffer），采集进程写入一帧，播放或编码进程消费一帧，中间只需要维护读写指针，缓冲区满则丢帧或阻塞。这套方案在不少嵌入式设备上跑得很稳。

6.3 多进程协作的服务器架构

Nginx的worker进程之间虽然通常不共享业务数据，但一些自研的高性能服务器会用共享内存维护全局计数器、配置热更新副本、或者各worker之间的负载指标。这些数据变更频繁、读多写少，共享内存搭配原子操作比加解锁的跨进程锁性能好很多。

6.4 不适合的场景

共享内存不是万能的。如果进程之间只是偶尔传个几百字节的请求，那就用消息队列或管道，引入共享内存反而要处理映射生命周期、同步、崩溃恢复等一系列问题，收益还覆盖不了复杂度。如果进程分布在多台机器上，那就老老实实用网络协议，共享内存只在本机生效。如果一个数据项只是定期变化、不要求实时性，那用文件读写加信号量也完全够用。

简单说，共享内存适用的是“高频、大数据量、低延迟”的进程间通信场景，其他场景选用更简单的IPC机制往往更省事。

7. 最后的工程化建议

代码能跑和代码能上线是两回事。共享内存在生产环境要稳定工作，除了API本身，还有很多工程化细节：

第一，生命周期管理要统一。我见过很多项目里共享内存是由各个业务进程自己创建和删除的，结果就是进程退出顺序不同导致清理不干净。比较好的做法是划分清楚：哪个进程负责创建、哪个进程负责删除，文档里写明，代码和文档保持一致。

第二，启动顺序要有保障。服务端创建共享内存后，客户端才连接。如果客户端启动早了，需要写重试逻辑，而不是一失败就退出。这个重试间隔可以固定，也可以用指数退避，避免启动瞬间一堆客户端同时重试打爆日志。

第三，所有的错误路径都要考虑清理。程序可能在任何一行崩溃，如果用shm_open创建了对象，之后某一步失败了，要有检查并shm_unlink的代码。这种RAII风格虽然C语言里没有，但可以用一个结构体包住fd和指针，配合atexit或信号处理器来做最后的清理。

第四，权限和安全要重视。共享内存是全局可见的，任何有权限的进程都能attach进来读取数据。如果存的是敏感业务数据，至少应该设置严格的权限位，并限制可访问用户组。更稳妥的方案是使用系统级安全模块来限制对特定共享内存对象的访问。

第五，好好利用已有的工具和库。Linux内核自带的工具只是一部分，生产环境可以考虑用现成的IPC封装库，比如Boost.Interprocess，或者一些消息中间件底层的共享内存传输模块，比自己反复造轮子靠谱。学API是一回事，把通信架构设计好是另一回事。

我在实际项目中的体会是：共享内存不难，难的是把它的边界想清楚。什么时候用、什么时候不用、谁来管、崩了怎么办，这四个问题搞定了，共享内存就是一把利器；没想清楚，就是一地鸡毛的调试噩梦。希望这篇文章能帮你把后者变成前者。