System V共享内存实战：从API到信号量同步与调试-代码聚汇网

System V共享内存实战：从API到信号量同步与调试

黑河市all·2026-10-01·阅读 23 GEO检测（免费）

共享内存System V进程间通信

|难度：普通|阅读约 30 分钟

接手这类博客比较有意思。之前我在自己的项目里折腾过管道和消息队列，总觉得有点绕，后来真正把 System V 共享内存用起来，才理解什么叫"用户态最直接的共享方式"。这篇文章我不打算搞那些又长又空的原理堆砌，直接按"从 API 到实战、再到排查问题"的顺序走，把我在实际工程里趟平过的坑都摆出来，希望对正在做 Linux 进程间通信的你有用。

在动手之前，先交代一个原则：System V 共享内存最大的价值是"零拷贝"。数据从进程 A 写到某个地址，进程 B 在同一地址上直接读到，中间不经过内核缓冲区。相比管道、消息队列动不动就把数据从用户态拷到内核态，再拷回用户态，"共享内存 + 信号量"这个组合在吞吐量和延迟上都有代差级优势。下面我们先把这套机制拆开。

1. 核心思路：为什么偏偏是共享内存

1.1 先搞清楚进程间通信的几条路

做过多进程开发的人都清楚，进程隔离是操作系统的基本规矩。一个进程的地址空间，另一个进程默认碰不到。那怎么交换数据？常见的方案我直接列出来对比：

通信方式	数据路径	是否零拷贝	适用场景	主要缺点
匿名管道/命名管道	用户态→内核态→用户态	否	父子进程、简单流式数据传输	单向、半双工、数据流无边界
System V 消息队列	用户态→内核态→用户态	否	小消息、异步通知	有长度限制，慢
System V 共享内存	直接映射同一物理页	是	大批量数据、高频读写	需要额外同步机制
POSIX 共享内存	直接映射同一物理页	是	大批量数据、跨进程	接口风格不同，命机管理等细节也多
套接字 (Unix Domain Socket)	用户态→内核态→用户态	部分支持	跨主机/跨进程通用	协议栈开销仍在

说到这里你可能已经看出来，共享内存是唯一一个不经过"内核中转站"的选择。它把同一块物理内存分别映射到不同进程的虚拟地址空间里，数据写下去后，另一个进程几乎能瞬间看到。

1.2 System V 与内核对象的关系

System V 共享内存本质上是一套 SysV IPC 机制的组成部分，这类机制共有三类：共享内存、消息队列、信号量。它们都有一个共同特征：在内核中维护IPC 对象，每个对象有一个非负整数的 ID，进程通过 ID 操作对象。

这个设计很像你在公司里租了一个公共储物柜。储物柜（物理内存）只有一个，租约凭证（IPC 对象）由管理员（内核）统一登记，谁拿着凭证谁就能开锁使用。这种"先申请资源、再获取操作权"的流程，基本决定了后续所有 API 的调用顺序。

我们这一篇主讲共享内存，所以后面的所有代码和命令都围绕 shm 开头的一组 API 展开。与 IPC 对象相关的还有权限位、所有者 uid/gid、创建时间等元信息，这些在内核对象生命周期里一直存在，直到你显式删除它。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 从零开始：共享内存的完整创建流程

2.1 第一步：用 ftok 生成唯一 key

共享内存对象的创建入口是 shmget，但它的第一个参数是 key_t 类型的 key。直接写死一个数字当然也行，但那很容易和系统里已有的 key 冲突。正规做法是用 ftok 从一个已存在的文件路径和一个项目 ID 生成一个几乎唯一的 key。

c复制#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/types.h>

key_t key = ftok("/tmp/myapp", 66);
if (key == -1) {
    perror("ftok");
    exit(EXIT_FAILURE);
}

ftok 的原理是把文件的 inode 编号和项目 ID 组合起来做哈希，所以只要文件路径不变、项目 ID 不变，生成的 key 就固定。这里有个注意事项：用于 ftok 的文件必须真实存在，否则直接返回 -1。我在项目里通常用程序自己的配置目录下的固定文件，比如 /etc/myapp/app.conf，保证各进程拿到的是同一个 key。

2.2 第二步：创建或获取共享内存对象

c复制int shmid = shmget(key, 4096, IPC_CREAT | IPC_EXCL | 0666);
if (shmid == -1) {
    // 如果已存在且未设置 IPC_EXCL，shmget 不会失败，而是返回已有对象的 ID
    shmid = shmget(key, 4096, IPC_CREAT | 0666);
    if (shmid == -1) {
        perror("shmget");
        exit(EXIT_FAILURE);
    }
}

这里有几个标志位，我实际使用中会重点区分：

IPC_CREAT：不存在就创建，存在则直接打开。
IPC_EXCL：和 IPC_CREAT 一起用，若对象已存在则返回 EEXIST 错误。这是典型的"要么我新建、要么就别碰旧的"的语义，适合防止多个服务端同时初始化。
权限位：0666 表示读写权限对所有用户开放。如果对权限敏感，按 umask 风格设计就行。

还有一点值得提：shmget 的第二个参数 size 是共享内存的字节数。内核会按页对齐分配，实际占用的物理内存可能是你传入 size 的向上取整页数。比如你传 4097，内核可能给你 8192 字节。如果你不确定到底分了多少，后面用 shmctl 的 IPC_STAT 命令查。

2.3 第三步：挂载共享区

到这一步，你还只是拿到了一个 shmid，它相当于一把钥匙，还没有把内存映射到进程地址空间。真正建立映射的是 shmat：

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

第二个参数传 NULL 表示让内核替你选择一个合适的挂载地址，这是最省心的方式。第三个参数通常传 0，表示以读写方式挂载。如果传 SHM_RDONLY，则这段内存只能读。

有个细节：shmat 返回的地址在同一个进程的不同调用中可能不同，而且也不保证多个进程看到相同的虚拟地址。这完全正常，因为每个进程的虚拟地址空间布局不一样，大家映射的是同一块物理页面，不是同一个虚拟地址。

2.4 第四步：分离与删除

用完共享内存后，要把映射从进程地址空间卸载：

c复制int ret = shmdt(addr);
if (ret == -1) {
    perror("shmdt");
    exit(EXIT_FAILURE);
}

注意 shmdt 只是断开当前进程的挂载关系，不会删除共享内存对象本身。真正删除对象要调 shmctl：

c复制struct shmid_ds buf;
shmctl(shmid, IPC_RMID, &buf);

删除之后，如果有其他进程仍然挂在这块内存上，它们还能继续访问，直到它们自己调 shmdt 或进程退出。所以"删除对象"和"彻底释放内存"不是一回事。这个坑我踩过，后面章节里专门展开讲。

3. 实战环节：用共享内存写一个多进程统计服务

3.1 服务端：初始化共享区并写入数据

光讲 API 不写完整的例子等于白看。我搭一个常见场景：一个主进程负责往共享内存里写入一批监控指标，一个或多个工作进程负责读取这些指标，做统计展示。先从服务端代码入手。

服务端初始化部分：

c复制// server.c
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/types.h>
#include <unistd.h>

#define SHM_SIZE 1024

typedef struct {
    int seq;
    double cpu_usage;
    double mem_usage;
    char msg[128];
} monitor_t;

int main() {
    key_t key = ftok("/tmp/monitor_app", 88);
    if (key == -1) { perror("ftok"); exit(1); }

    int shmid = shmget(key, sizeof(monitor_t), IPC_CREAT | IPC_EXCL | 0666);
    if (shmid == -1) {
        perror("shmget");
        exit(1);
    }

    monitor_t *p = (monitor_t *)shmat(shmid, NULL, 0);
    if (p == (monitor_t *)-1) { perror("shmat"); exit(1); }

    int count = 0;
    while (1) {
        p->seq++;
        p->cpu_usage = 30.0 + (rand() % 500) / 10.0;
        p->mem_usage = 50.0 + (rand() % 300) / 10.0;
        snprintf(p->msg, sizeof(p->msg), "sample-%d", p->seq);
        printf("[server] wrote seq=%d cpu=%.2f mem=%.2f\n",
               p->seq, p->cpu_usage, p->mem_usage);
        count++;
        sleep(1);
    }

    shmdt(p);
    shmctl(shmid, IPC_RMID, NULL);
    return 0;
}

这段代码有一个很明显的"问题"：进程挂上共享内存后，循环写数据；但现实中一旦出现两个服务端进程同时初始化，IPC_CREAT | IPC_EXCL 就会导致第二个进程失败，这其实是好事。真正常见的写法是：服务端先试着 shmget(key, size, IPC_CREAT | IPC_EXCL | 0666)，如果失败且错误码是 EEXIST，则说明对象已经存在，再用普通 IPC_CREAT 打开它，让整个程序具备"单实例写、多实例读"的能力。

3.2 客户端：读取共享区的实时数据

客户端相对简单，只负责 shmat 然后循环读数据：

c复制// client.c
#include <stdio.h>
#include <stdlib.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <sys/types.h>
#include <unistd.h>

typedef struct {
    int seq;
    double cpu_usage;
    double mem_usage;
    char msg[128];
} monitor_t;

int main() {
    key_t key = ftok("/tmp/monitor_app", 88);
    if (key == -1) { perror("ftok"); exit(1); }

    int shmid = shmget(key, sizeof(monitor_t), IPC_CREAT | 0666);
    if (shmid == -1) { perror("shmget"); exit(1); }

    monitor_t *p = (monitor_t *)shmat(shmid, NULL, 0);
    if (p == (monitor_t *)-1) { perror("shmat"); exit(1); }

    int last_seq = 0;
    while (1) {
        if (p->seq != last_seq) {
            printf("[client] read seq=%d cpu=%.2f mem=%.2f msg=%s\n",
                   p->seq, p->cpu_usage, p->mem_usage, p->msg);
            last_seq = p->seq;
        }
        usleep(200000);
    }

    shmdt(p);
    return 0;
}

这段代码明显有一个竞争力问题：两个进程在同一时间对同一块内存做读写，如果中间隔了个 sleep(1)，看起来问题不大。但要真把它直接放进生产环境，你很快会撞上"读到半个结构体"的经典坑。因为 monitor_t 里是 int、double、char 数组混合结构，写入方写 seq 和 cpu_usage 之间，读取方可能就同时观察到两者不一致。

3.3 同步与并发：为什么必须配信号量

共享内存只解决"数据可见"的问题，不解决"数据一致"的问题。想保证读写互斥，最经典的配套方案是 System V 信号量。

我记得自己做监控项目时，最开始图省事没加信号量，结果客户端多次读到 CPU 使用率是 87.5、内存使用率却还停留在上一轮的 43.2。后来补上信号量，代码骨架就成了这样：

c复制// 伪代码：写前申请信号量
struct sembuf sb = {0, -1, SEM_UNDO};
semop(semid, &sb, 1);

// 写共享内存
memcpy(p, &tmp, sizeof(monitor_t));

// 写后释放信号量
sb.sem_num = 0; sb.sem_op = 1; sb.sem_flg = SEM_UNDO;
semop(semid, &sb, 1);

SEM_UNDO 这个标志非常关键，它让内核在进程意外退出时自动撤销信号量操作，避免死锁。这个设计比 POSIX 信号量多一层保险，也是我在工程里愿意用 System V 信号量的原因之一。

3.4 看看实际测试结果

我在本机用两个终端分别跑 server 和 client，输出大致如下：

text复制[server] wrote seq=1 cpu=32.10 mem=51.40
[client] read seq=1 cpu=32.10 mem=51.40 msg=sample-1
[server] wrote seq=2 cpu=41.70 mem=53.80
[client] read seq=2 cpu=41.70 mem=53.80 msg=sample-2

如果我在 server 和 client 之间加一个统计：传 100 条 512 字节的数据块，对比共享内存和消息队列的时间开销，共享内存至少能快出 3～5 倍。因为这里完全没有 copy_from_user 和 copy_to_user 的内核拷贝。

4. 查看与调试：ipcs 工具的正确用法

4.1 ipcs 命令：看共享内存的状态

写代码是一回事，排查问题才是日常大头。Linux 下查看共享内存最常用的就是 ipcs：

bash复制ipcs -m

输出示例：

text复制------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x00000058 12345      root       666        1024       2

各列含义我拆一下：

key：创建时用的 key，十六进制展示。
shmid：共享内存对象 ID，ipcrm 删对象时要用它。
nattch：当前有多少个进程挂了这块共享内存。
bytes：对象大小。

nattch 特别值得盯着看。如果你发现进程退出后 nattch 还大于 0，大概率是有进程没调 shmdt，或者它有子进程没退出干净。这时候别急着删共享内存，先查是哪个进程还挂着。

4.2 用 ipcrm 删除残留对象

调试过程中最头疼的莫过于"旧的共享内存对象残留"。因为 System V 对象不随进程退出自动消失，如果不手动删，就会一直占用 key 和内存。删法很简单：

bash复制ipcrm -m 12345

如果图省事，也可以按 key 删：

bash复制ipcrm -M 0x00000058

我有一次在测试环境里忘了删，导致下一轮测试时 shmget 返回的总是旧对象，数据一直是上一轮的残留。加了 IPC_EXCL 又直接报 EEXIST，排查了好一阵子才反应过来。所以正规工程项目启动时，通常会加一个"检测到旧对象就清理"的逻辑，或者至少写进 Makefile 的 clean 目标。

4.3 查看内核限制参数

共享内存也不是想开多大就开多大。内核有几组参数限制，最常见的查看方式是：

bash复制ipcs -lm

输出里重点看 SHMMNI（系统共享内存对象最大数量）、SHMSEG（单进程可挂载的最大段数）、SHMALL（共享内存总页数上限）。一般默认值对普通应用够用，但如果你做的是 image 处理、视频帧缓冲这类动辄几十 MB 甚至上百 MB 的大块共享区，可能会碰到限制。修改方法是在 /etc/sysctl.conf 里设置：

text复制kernel.shmmax = 1073741824
kernel.shmall = 268435456

改完 sysctl -p 生效。这些参数如何合理配置，后面我会单独写一篇，这里只提一点：shmmax 是单块共享内存最大字节数，shmall 是系统允许共享内存页面总数。很多 MySQL 调优文章说设置 shmmax=1GB、shmall=2GB 之类，就是这个道理。

5. 实战最大的坑：共享内存生命周期和权限管理

5.1 进程退出后，共享内存为什么不消失

新手最容易懵的一处就是：程序里明明 return 了，ipcs -m 却还能看到那块共享内存。原因在于 System V IPC 的生命周期独立于任何一个进程。进程把 shmat 挂上，只是增加了对象的一个引用计数；进程崩溃或正常退出，引用计数减一，但对象本身仍然在内核中。

这个设计有它的历史原因：System V IPC 从早期 UNIX 一路传下来，本身就被设计成"内核持久化"的资源，适用于那种"启动一个服务、写入配置、退出，后面别的进程还要读"的场景。但在现代应用中，很多人更喜欢 POSIX 或 mmap 风格，因为进程退出自动清理，省心得多。

如果你非要让 System V 共享内存随最后一个进程退出而消失，办法是让某个进程在退出前调 shmctl(shmid, IPC_RMID, NULL)，并且确保其它进程已经 shmdt。否则就会出现"删了对象但内存还没释放"或者"释放了但引用计数不为零"的中间态。

5.2 权限和所有权：共享内存也有"属主"

System V 共享内存对象有 owner uid/gid 和权限模式。创建对象时，owner 是创建者的 uid。如果另一个用户想 shmat，内核按权限位判断。0666 表示所有人可读写；0640 表示属主可读写、同组可读、其他人不可访问。

这里有个我在多用户服务器上面踩过的真实问题：同一个数据目录被多个服务共同维护，A 用户先启动了创建共享内存的服务，B 用户的服务后续尝试 shmget 时，即使 key 一样，也拿不到写权限。因为权限位只设了 0644，B 用户不是属主也不是同组，只能读不能写。解决方法很简单：要么统一用 root 启动，要么在创建时设 0666，要么在 init 阶段用 root 把所有相关进程拉起来再降权。

5.3 动态扩容：共享内存能不能变长

答案是不能在创建后直接改大小。shmget 创建时指定了大小，之后 shmctl 的 IPC_SET 只能改权限、属主等元信息，不能改 size。想扩大共享区，只能新建一块更大的对象，拷数据，再删旧的。

这带来一个设计上的启示：做共享内存规划时，size 要充分考虑未来扩展。我在日志采集系统里就吃过亏，当初按 4KB 定义一条记录，后来想加一个字段，所有客户端结构体都变大了，但共享内存还是旧的 4KB，写指针直接越界。最后没办法，在结构体里预留了一段 pad 字段，并在头部加版本号和长度字段，才彻底解决问题。

5.4 初始化陷阱：共享内存不帮你清零

还有一个容易被忽略的事：刚创建出来的共享内存，内容不保证是全零，可能是上次使用留下的垃圾数据。所以创建端在初始化时一定要自己清零：

c复制memset(p, 0, sizeof(monitor_t));

或者用 shmctl 配合 shmat 后手动初始化。如果你读过 POSIX 共享内存，会发现 ftruncate 之后也需要自己去清。本质上这两套机制都属于"内核只分配物理页，不管理内容"。这个细节能避免你在 debug 时看到一堆莫名其妙的乱码数据。

6. 经验总结与使用建议

6.1 哪些场景适合 System V 共享内存

就我的经验，下面的场景最适合用它：

高频写低频读的监控指标采集，比如每 100ms 更新一次数据，其他模块随时读取当前值。
大批量数据传输，比如视频帧、图片压缩数据、科学计算中间结果。
多进程共享配置，启动时由管理进程写一份，各工作进程只读。

相反的，如果只是低频小数据交互，用消息队列或 Unix Domain Socket 更好，别把同步问题引进来。

6.2 和 POSIX 共享内存怎么选

这个话题我经常被问到。简单说：System V 更适合"内核对象长期存在、整套信号量机制配套齐全"的老派做法；POSIX 接口更清爽，用文件描述符、mmap 和 ftruncate 处理，配合 sem_open 也不错。

但有一点必须承认：System V 的 SEM_UNDO 特性很好用，崩溃时内核会补偿信号量操作，减少死锁概率。如果团队里都是老 C/C++ 程序员，维护过 UNIX 系代码，原生 System V 一点也不落伍。

6.3 调试共享内存的心法

最后说点工具链之外的东西。排查共享内存问题，我的路径基本固定：

先用 ipcs -m 看对象是否存在、大小对不对、引用计数正不正常。
如果数据对不上，先怀疑同步问题，检查信号量有没有加，SEM_UNDO 有没有写。
再用 strace 跟踪 shmat、shmdt 调用，确认进程实际挂载和分离的时机。
最后用 gdb 附加读写进程，在共享区首地址上 x/64gx 看原始内容，判断是不是结构体定义不一致。

通过这套路径，我修过不少"看起来随机崩溃、实际是并发访问"的疑难杂症。总而言之，共享内存不是魔法，它只是把数据通路最陡的那段坡给铺平了。你负责装的护栏和红绿灯——也就是同步机制——才是真正决定项目稳不稳定的因素。写到这里，想起自己第一次调试共享内存野指针时按着头看 ipcs 的那个下午，希望这篇文章能帮你少走点弯路。