Linux IPC机制详解：管道、共享内存与消息队列避坑选型

1. 一次阻塞到凌晨的排查：IPC选错到底要付多少代价

凌晨一点半，我盯着一个"应该早就退出"的采集进程，它在read()上纹丝不动。上游进程明明已经处理完数据并exit(0)了，下游却像被施了定身术，既不报错也不返回。当时第一反应是死锁，加了gdbattach 上去看调用栈，卡在read上，参数是那个管道 fd。折腾了四十分钟之后我才反应过来：上游 fork 出来的那个后台子进程，还攥着管道写端没撒手。写端没全关，EOF 就永远不来，读端也就永远等下去。

这就是 Linux 进程间通信（IPC）最典型的性格：它给你极其丰富的工具箱——管道、FIFO、共享内存、消息队列、信号量、信号、Unix domain socket、eventfd、memfd——但每一样都有自己的脾气，选错工具或者少写一行关闭逻辑，代价可能就是一次深夜加班。IPC 本身不是"把数据从 A 送到 B"这么简单，它真正解决的问题是三件事：数据怎么传、谁先谁后的顺序怎么保证、对方死了或者卡住了我怎么办。很多教程只讲第一件，剩下两件全靠你在生产环境里用故障去换。

这篇内容我打算把 Linux IPC 这套东西按"机制原理—代码骨架—真实坑点—选型逻辑"的顺序捋一遍。适合已经会写基本 Linux C 程序、但在多进程架构里踩过或者即将踩坑的开发者；如果你平时用 Python、Go 或者 Java，也能看懂，因为这些机制的语义是跨语言通用的，只是封装层不同。全程我会尽量给出可以直接抄的代码片段，以及一份我自己的选型对照表。

我要先讲清楚一个贯穿全文的判断标准：没有任何一种 IPC 是"最好"的，只有在特定约束下"最合适"的。低延迟、高吞吐、跨主机、可持久化、天然支持多对多——这些需求两两之间往往是冲突的，你的任务不是找银弹，而是在约束条件下做减法。下面就按"从最轻到最重"的顺序拆。

2. 管道与FIFO：内核里那条只有64KB的传送带

2.1 匿名管道：fork之后的那根脐带

管道是所有 IPC 里最古老、最简单、也最容易想当然的一个。pipe()返回两个 fd，一个读端一个写端，本质上就是内核里一块环形缓冲区，配上一对读写指针。它最典型的使用姿势是：父进程先pipe()，再fork()，子进程继承这两个 fd，然后各自关掉自己不需要的那一端。

// 父进程写，子进程读 int fds[2]; if (pipe(fds) < 0) { perror("pipe"); exit(1); } pid_t pid = fork(); if (pid == 0) { close(fds[1]); // 子进程不需要写端，必须关掉 char buf[256]; ssize_t n; while ((n = read(fds[0], buf, sizeof(buf))) > 0) { // 处理数据 } close(fds[0]); _exit(0); } close(fds[0]); // 父进程不需要读端 write(fds[1], "hello", 5); close(fds[1]); // 写完必须关，否则子进程永远等不到 EOF waitpid(pid, NULL, 0);

这里有两个"必须关"的动作，对应我开头踩的那个坑：子进程要关掉写端，父进程写完要关掉写端。原因是read()返回 0（也就是 EOF）的触发条件不是"缓冲区空了"，而是"所有持有写端的进程都关闭了写端"。只要还有一个进程攥着写端不放——哪怕它根本没写过数据——read()就会继续阻塞。这一点在 fork 出多级子进程、或者用system()/popen()时会变得非常隐蔽，因为那些后台进程很可能悄悄继承了你的 fd。

顺便说一个相关的细节：open系列默认继承的 fd 在exec之后仍然保留。如果你用popen起了个 shell 脚本，脚本里又nohup了一个守护进程，那这个守护进程就继承了你管道写端的副本，你后面所有read都可能被它拖住。解决办法有两个：一是创建 fd 时加O_CLOEXEC（pipe2(fds, O_CLOEXEC)），二是在 fork 之后手动关闭。我现在的习惯是无脑加 O_CLOEXEC，因为在复杂的模块依赖里，你很难靠人工审查保证每个分支都关了。

2.2 管道缓冲区大小与PIPE_BUF的原子性边界

管道缓冲区在 Linux 上的默认容量是 65536 字节（16 个内存页），可以通过fcntl(fd, F_SETPIPE_SZ, size)调整，上限受/proc/sys/fs/pipe-max-size约束，普通用户一般最多能调到 1MB 左右。缓冲区满了会怎样？如果写端是阻塞模式，write()会挂起；如果是O_NONBLOCK，返回 -1 并置errno为EAGAIN。这是所有"带背压的流式传输"的基础。

真正需要刻进肌肉记忆的是PIPE_BUF这个值。Linux 上它是 4096 字节。它的含义是：当写入长度小于等于 PIPE_BUF 时，这次写是原子的——多个进程往同一个管道写，数据不会互相穿插。一旦超过这个值，内核可能分多次搬运，别的进程的写入就可能插到中间。如果你在做多生产者场景（比如多个 worker 往一个统计管道里打点），消息一旦超过 4KB，就必须自己在应用层加锁，或者改用带有消息边界的机制（消息队列、SEQPACKET socket）。

还有一个隐形的坑：read()不保证一次读满你请求的字节数。管道是字节流，不是消息流，内核只是"有多少给多少"。如果你写了 100 字节两次，读端可能一次读到 200，也可能分三次读完。所以应用层必须自己处理"粘包"和"拆包"，常见做法是加长度前缀，或者干脆约定用\n分隔。这一点是我见过新手翻车最多的地方，很多人以为管道像消息队列一样有消息边界。

2.3 命名管道FIFO：把管道挂到文件系统上

匿名管道有个硬伤：只有在有亲缘关系的进程之间才能用。两个毫无关系的进程想通信，就得用 FIFO，也就是命名管道。mkfifo("/tmp/myfifo", 0666)之后，那个路径就变成了一个特殊文件，任何有权限的进程都能像打开普通文件一样open()它。

mkfifo /tmp/myfifo # 终端 A cat /tmp/myfifo # 终端 B echo "hello from B" > /tmp/myfifo

FIFO 的打开语义有个很容易踩的细节：以只读方式open()一个 FIFO 会阻塞，直到有进程以写方式打开它，反之亦然。这在单进程测试时会让人以为程序卡死了。想避开就加O_NONBLOCK，此时只读打开会立刻返回成功，只写打开如果没人读会返回ENXIO。

FIFO 还有一个常年存在的顽疾：残留文件。进程异常退出时不会自动清理 FIFO 文件，下次启动mkfifo就会报EEXIST。正确的做法是启动时先unlink再创建，并且要处理好"两个进程同时启动"的竞态——一般用一个 mkdir 锁目录或者 flock 来串行化初始化过程。

2.4 实战中三个容易翻车的点

第一，SIGPIPE。读端全部关闭后还继续往管道写，内核会给写进程发SIGPIPE，默认行为是直接杀掉进程。很多人调试时发现程序莫名其妙没了，就是这个原因。标准做法是在程序启动早期就signal(SIGPIPE, SIG_IGN)，然后自己处理write返回的EPIPE。网络编程里这条几乎是必备操作。

第二，半关闭。管道不能只关一半方向再继续用另一半，它只有整体关闭。如果你的协议里需要"我发完了，但还要收"，管道就不合适，得用 socket。

第三，跨进程传输大量数据。管道的两次用户态—内核态拷贝（写一次，读一次）在高吞吐场景下是明显瓶颈。100MB/s 以上的数据流，管道很快就会成为 CPU 占用的主要来源，这时候就该考虑共享内存了。

3. 共享内存：性能天花板，也是同步地狱

3.1 共享内存为什么快：省掉的到底是哪一次拷贝

要理解共享内存的价值，先得理解其他 IPC 慢在哪。管道、消息队列、socket 的数据路径都是：发送方用户态 → 内核缓冲区 → 接收方用户态，数据被搬了两趟。共享内存的思路是：内核分配一块物理内存，然后同时映射进两个进程的虚拟地址空间，发送方直接往这块内存写，接收方直接读，中间不经过任何系统调用的搬运。

严格说这不是"零拷贝"，而是把两次拷贝压缩成一次：生产者写数据的那一次仍然存在，但它写的就是双方共用的那片内存，消费者拿到的指针直接指向它。对于大块数据（几百 KB 到几 GB 都不稀奇），这个差距是数量级的。

代价同样巨大：内核不再帮你做任何同步。管道有缓冲区满/空的天然流控，共享内存没有。你写完一段数据，对方怎么知道写完了？两个进程同时写同一块区域怎么办？这些全靠你自己设计同步协议。所以我一直有个观点：共享内存的难点从来不是"映射"那几行代码，而是它后面跟着的同步方案。

3.2 mmap匿名映射与shm_open两条路径

父子进程之间传数据，最省事的是匿名映射：

size_t size = 4096; int *shm = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0); if (shm == MAP_FAILED) { perror("mmap"); exit(1); } shm[0] = 0; pid_t pid = fork(); if (pid == 0) { shm[0] = 42; // 子进程写入 _exit(0); } waitpid(pid, NULL, 0); printf("%d\n", shm[0]); // 父进程能看到 42

关键在MAP_SHARED，如果写成MAP_PRIVATE，那就是写时复制，双方各改各的，谁也看不见谁。这个字母之差排查起来极其费劲，因为程序不报错，只是数据"不同步"。

无亲缘关系的进程要用 POSIX 共享内存，走shm_open加ftruncate加mmap三步：

int fd = shm_open("/my_shm", O_CREAT | O_RDWR, 0666); ftruncate(fd, size); // 必须先定大小，否则 mmap 会被 SIGBUS 干掉 void *p = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); // ... 使用 munmap(p, size); close(fd); shm_unlink("/my_shm"); // 用完删名字

注意ftruncate那一步。共享内存对象创建时长度为 0，如果你跳过它直接mmap然后访问，程序会收到SIGBUS而不是友好的错误码——这是因为映射建立时对象是空的，一旦访问超出实际文件大小的页，内核找不到对应的后备存储。这个 bug 我第一次遇到时对着"非法地址"的报错查了半天，最后才意识到是ftruncate漏了。

3.3 System V与POSIX：两代API的取舍

Linux 上共享内存有两条并行的路线：老一代 System V 的shmget/shmat/shmdt，和新一代 POSIX 的shm_open/mmap。它们的对比如下：

我的建议很直接：新项目一律用 POSIX 那套。理由不是它更快，而是它把共享内存统一成了"文件"心智模型，权限、清理、映射偏移这些事都能复用你已经熟悉的文件操作经验。System V 那套现在还在维护，基本都是历史包袱——我在一个十几年的老系统里见过ipcs -m列出几十个没人记得用途的段，谁都不敢删，因为不知道哪个进程还在用。

3.4 同步才是真正的难点：信号量与futex

共享内存裸用一定会出问题。最基础的同步需求是"生产者写完，消费者才能读"。朴素做法是加个标志位：

// 生产者 shm->data = value; __sync_synchronize(); // 内存屏障，防止编译器/CPU 重排 shm->flag = 1;

这里必须插内存屏障，否则编译器可能把flag = 1重排到data = value之前，CPU 也可能乱序执行，消费者就会读到"标志已置位但数据还是旧的"的状态。这是无锁编程的入门坑，也是我认为共享内存最反直觉的地方——你写的代码顺序不代表实际执行顺序。

有锁的方案更稳妥。POSIX 提供了专门为共享内存设计的信号量：

sem_t *sem = sem_open("/my_sem", O_CREAT, 0666, 1); sem_wait(sem); // P 操作，计数减一，为 0 则阻塞 // 临界区 sem_post(sem); // V 操作，计数加一，唤醒等待者

对于进程间共享的未命名信号量，必须用sem_init(&sem, 1, 1)，第二个参数pshared=1表示进程间共享。这个参数如果写成 0，信号量只在当前进程内有效，多进程场景下形同虚设，而且不会报错——又是一个静默失效的坑。

Linux 特有的futex（快速用户态互斥）是更底层的原语，glibc 的 pthread mutex 就是基于它实现的。直接用它的人不多，但理解它的思路有价值：大部分情况下不需要进内核，只有在真正发生竞争时才通过FUTEX_WAIT陷入内核睡眠。这是 Linux 上高性能同步的关键设计思想。实践中你用PTHREAD_PROCESS_SHARED属性的 pthread mutex 就够了：

pthread_mutexattr_t attr; pthread_mutexattr_init(&attr); pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED); pthread_mutexattr_setrobust(&attr, PTHREAD_MUTEX_ROBUST); // 防止持锁进程崩溃导致死锁 pthread_mutex_init(&shm->mutex, &attr);

PTHREAD_MUTEX_ROBUST这个属性值得单独提一句。共享内存上的互斥锁最怕的就是持锁进程突然崩了，锁永远不释放，其他进程集体饿死。robust 属性让内核在持锁进程死亡时把锁标记为EOWNERDEAD，让下一个pthread_mutex_lock的调用者知道"上一个主人死了，你去收拾残局"，你可以在那里把共享数据恢复成一致状态。这个机制我在一个需要长期运行的采集服务里用过，效果很好，省掉了一大堆"进程崩溃后必须整体重启"的运维麻烦。

3.5 /dev/shm残留和权限那些事

POSIX 共享内存的实体在/dev/shm/下，是个 tmpfs，数据在内存里，重启即消失。这既是优点（不怕脏数据），也是隐患（不能持久化）。如果进程崩溃没调shm_unlink，名字会一直留在那里，下次O_CREAT打开的是旧对象，里面可能残留上次的数据，长度也可能不对。典型的症状是"程序重启后行为诡异，改代码也没用"。

排查命令就一个：

ls -l /dev/shm/ # 看有哪些残留 ipcs -m # System V 的段 ipcrm -m <shmid> # 手动删除

另外注意/dev/shm的大小受 tmpfs 默认限制（通常是物理内存的一半），一个几百 GB 的共享内存请求会直接失败。这个值可以通过挂载参数调整。

4. 消息队列：被严重低估的"带边界的字节流"

4.1 消息边界才是消息队列的核心价值

如果我只能用一个词概括消息队列跟管道的区别，那就是边界。管道是字节流，消息队列是消息流：你mq_send一条 100 字节的消息，对方mq_receive拿到的就是完整的一条 100 字节，不会多也不会少，更不会两条粘一起。相册.book

#include <mqueue.h> mqd_t mq = mq_open("/my_queue", O_CREAT | O_RDWR, 0666, NULL); struct mq_attr attr; mq_getattr(mq, &attr); // 默认 mq_maxmsg=10, mq_msgsize=8192 printf("maxmsg=%ld, msgsize=%ld, curmsgs=%ld\n", attr.mq_maxmsg, attr.mq_msgsize, attr.mq_curmsgs); mq_send(mq, "task-1", 7, 0); // 最后参数是优先级 char buf[8192]; unsigned int prio; ssize_t n = mq_receive(mq, buf, sizeof(buf), &prio);

默认配置是"最多 10 条消息，每条最大 8192 字节"，这个默认值在真实项目里几乎一定要改。你可以在mq_open时通过 attr 指定，但要注意两个上限受/proc/sys/fs/mqueue/msg_max和msgsize_max约束，普通用户改不了。容量给太大还有个副作用：消息队列占用的内存不归你的进程统计，出问题时用top看不出来，得用ipcs或者/proc/sys/fs/mqueue相关文件排查。

4.2 优先级机制和它的适用边界

消息队列的第二个特色是优先级。mq_send的最后一个参数越大优先级越高，mq_receive永远先拿优先级最高的消息。这看起来很美，但有个反直觉的点：相同优先级之间是 FIFO，不同优先级之间是严格抢占。这意味着如果你给某个高优先级消息持续投喂，低优先级的消息可能永远排不上队。我在一个日志采集系统里见过这个问题——错误日志被设成高优先级，结果正常日志在高峰期全被饿死，最后不得不给正常日志也做限流。

所以优先级要慎用，它适合表达"控制指令 > 业务数据"这类层次分明的场景，不适合表达业务内部的重要性差异。

4.3 阻塞策略与mq_notify

mq_receive默认是阻塞的，队列空就一直睡。可以用O_NONBLOCK打开，空了返回EAGAIN。但如果你想让消息到达时主动通知，而不是轮询或阻塞，POSIX 提供了mq_notify：注册一个信号或者线程回调，队列从空变成非空时触发一次。

注意：mq_notify的通知是"边沿触发"的。它只在队列由空转非空的那一刻通知一次，如果你的处理函数没有把队列读空，后续消息不会再次触发通知。所以标准用法是在回调里while (mq_receive(..., O_NONBLOCK) > 0)一直读到EAGAIN为止，然后重新注册mq_notify。

这套机制对写事件循环的人来说不太友好，因为信号处理函数里不能做复杂操作（后面会讲），Linux 上更推荐的做法是配合eventfd或者直接用 Unix domain socket 代替。

4.4 System V消息队列还剩什么价值

msgget/msgsnd/msgrcv这一套比 POSIX 版本更老，但有一个 POSIX 没有的特性：msgrcv可以按"消息类型"选择性地接收，而不只是按优先级。这在某些需要按类型分发处理的多消费者场景里挺方便，不用自己做类型路由。

不过我还是那句话，新项目优先 POSIX。System V 消息队列最大的问题是清理：ipcs -q里堆积的队列不会自动消失，进程崩了队列还在，重启应用会发现旧消息还在里面等着被消费，行为完全不可预期。用 POSIX 的好处是它在/dev/mqueue下有名有姓，ls一下就能看个大概。

5. 信号与信号量：名字很像，用途完全不同

5.1 信号：最轻量，也最容易丢

信号是 Linux 上最"异步"的 IPC——它不传数据（除了sigqueue能带一个整数），只传一个编号，含义是"发生了一件事"。它的优势是轻量、无需建立任何连接，进程随时能用kill(pid, SIGUSR1)通知另一个进程。

但它有三个硬伤，每一个都能让程序出诡异 bug。

第一个是不排队。同一信号连续来两次，如果进程还没处理第一次，第二次会被丢弃，最终只处理一次。内核里每个信号只维护一个 pending 位，不是队列。要做计数通知，必须用实时信号SIGRTMIN起的那些（它们是排队的），或者干脆用eventfd。

第二个是天然竞态。如果你用"冰箱里有信号就处理任务"这种模式，检查信号和进入睡眠之间有一个窗口期，信号可能恰好落在这个窗口里丢掉。正统的解法是把信号先sigprocmask屏蔽，处理完再解锁，配合sigsuspend原子地等待。但更现代的做法是根本不这么设计。

第三个是信号处理函数的限制。信号处理函数运行在任意时刻，它调用的大多数函数都是不安全的（不是可重入的）。printf、malloc、free这些都不能在信号处理函数里用，因为它们内部可能持有锁，而信号可能正好打断了一个持锁的操作。安全做法是只在处理函数里设置一个volatile sig_atomic_t标志位，主循环检测标志位再干活：

static volatile sig_atomic_t g_stop = 0; void on_sigint(int sig) { g_stop = 1; // 只做这一件事 } int main(void) { struct sigaction sa = {0}; sa.sa_handler = on_sigint; sigemptyset(&sa.sa_mask); sigaction(SIGINT, &sa, NULL); while (!g_stop) { // 主循环 } }

关于sigaction里的sa_flags，SA_RESTART值得特别说：不加它的时候，被信号打断的慢系统调用（比如read）会返回 -1 并置EINTR；加了之后内核会自动重启这些调用。哪个更好取决于你的场景——对于一个"等数据"的读循环，你希望信号来了能立刻跳出，那就别加SA_RESTART，但要记得处理EINTR。我见过太多代码因为没处理EINTR而在偶发信号下"读失败"提前退出。

5.2 signalfd：把信号接入事件循环

如果你的程序有epoll事件循环，信号会是个麻烦：它在任何地方打断你，而你想让它变成一个"事件"。Linux 从 2.6.22 开始提供了signalfd，可以把信号转成 fd，直接扔进epoll：

sigset_t mask; sigemptyset(&mask); sigaddset(&mask, SIGINT); sigaddset(&mask, SIGTERM); sigprocmask(SIG_BLOCK, &mask, NULL); // 必须先屏蔽，否则信号走默认路径 int sfd = signalfd(-1, &mask, SFD_NONBLOCK | SFD_CLOEXEC); // 之后 epoll_ctl 把这个 sfd 加进去，读 sfd 就是取信号

这个模式的好处是彻底消灭了"信号处理函数的可重入限制"和"竞态窗口"，所有逻辑集中在事件循环里，跟我平时写网络代码的心智模型完全一致。前提是先屏蔽再创建 signalfd，忘了屏蔽的话信号会走默认处理，signalfd 那一路收不到，又是一个静默失效。

5.3 信号量：它跟信号没有任何关系

新手最容易混淆的一对概念就是"信号"和"信号量"。它们中文名只差一个字，但机制、用途、API 全都不同。

信号量是一个计数器，用于控制"同时有几个进程能进入临界区"。计数大于 0 时sem_wait通过并减一；等于 0 时阻塞等待，直到别人sem_post加一唤醒。它最常见的用途有这么几类：

• 互斥：初值设为 1，就是一把二进制锁，保护共享内存。
• 限流：初值设为 N，控制最多 N 个 worker 同时消费某类资源。
• 事件通知：初值设为 0，生产者sem_post，消费者sem_wait，天然实现"你发我等"的握手，而且计数会累积，不会像信号那样丢失。

第三点经常被忽略：信号量其实是一种很好用的"不丢事件的信号"。生产得快、消费得慢，计数会一直涨，消费者追上来之后能连续处理多次。相比之下信号只能告诉你"有事发生"，具体几次说不清。

POSIX 信号量分命名和未命名两种。命名信号量sem_open("/name", ...)存在于/dev/shm/sem.*，跨无亲缘进程用；未命名信号量sem_init(&s, pshared, value)则适合放在共享内存里。清理上同样是命名信号量容易残留，程序退出时记得sem_unlink。

有个细节值得提醒：sem_wait被信号打断会返回EINTR，虽然会把信号量的值恢复，但你的代码需要重试。写循环的时候把它包成一个"要么成功要么彻底失败"的辅助函数，能省掉很多分散的重试逻辑。

6. Unix domain socket与新一代轻量积木

6.1 UDS的三种类型与凭据鉴权

Unix domain socket（UDS）是我在本地多进程架构里用得最多的一种，因为它把 socket 的丰富语义（双向、消息边界、连接管理）和本地通信的低开销结合在了一起。地址就是文件系统里的一个路径：

int fd = socket(AF_UNIX, SOCK_SEQPACKET, 0); struct sockaddr_un addr = {0}; addr.sun_family = AF_UNIX; strncpy(addr.sun_path, "/tmp/my.sock", sizeof(addr.sun_path) - 1); unlink("/tmp/my.sock"); // 清理旧 socket 文件 bind(fd, (struct sockaddr *)&addr, sizeof(addr)); listen(fd, 128);

三种类型要按需选：SOCK_STREAM是字节流，跟 TCP 手感一样，需要自己处理粘包；SOCK_DGRAM保留消息边界但不保证顺序和可靠投递；SOCK_SEQPACKET是我最推荐的——既保留消息边界，又保证顺序和可靠，非常适合自定义协议，一条请求一条响应发过去，接收端一次recv就能拿到完整消息，不用写解析状态机。

UDS 还自带一个超级实用的能力：对端身份鉴权。通过SO_PEERCRED可以拿到连接对端的 pid、uid、gid：

struct ucred cred; socklen_t len = sizeof(cred); getsockopt(conn_fd, SOL_SOCKET, SO_PEERCRED, &cred, &len); printf("peer pid=%d uid=%d gid=%d\n", cred.pid, cred.uid, cred.gid);

这意味着一台机器上的服务可以只允许特定用户调用，而且这个判断由内核提供，无法伪造。很多系统级的本地服务（比如系统日志、容器运行时）都靠这个做权限控制。相比之下，用 TCP 的 127.0.0.1 就只能靠 token 之类的应用层手段，安全性差一层。

6.2 抽象命名空间：不落盘的socket路径

UDS 默认要在文件系统里占一个路径，这带来了跟 FIFO 一样的残留问题：进程崩了 socket 文件还在，下次bind报EADDRINUSE。Linux 提供了一个替代方案——抽象命名空间：把地址的第一个字节设为\0，这个 socket 就不落盘，纯粹存在于内核里，进程退出内核自动回收。

addr.sun_path[0] = '\0'; // 抽象命名空间 memcpy(addr.sun_path + 1, "my_abstract", 11); bind(fd, (struct sockaddr *)&addr, sizeof(sa_family_t) + 1 + 11);

它的缺点是依赖 Linux 特有行为，跨平台不可移植，而且因为是匿名的，ls看不到，排查时得用ss -x或者/proc/net/unix。我的经验是：一旦服务是长期运行的系统组件，用抽象命名空间能省掉一大堆启动脚本里的清理逻辑；如果需要在其他 Unix 上跑，就乖乖用文件路径并且写unlink的容错逻辑。

6.3 eventfd、timerfd、memfd：为事件循环准备的积木

这三样东西都是 Linux 特有的轻量设施，共同点是都是 fd，都能塞进 epoll，非常适合在单线程事件循环里做进程间协作。

eventfd是一个内核维护的 64 位计数器。write加值，read取值并清零（或减去指定值）。它最常见的用法是唤醒：工作线程往 eventfd 写一个 1，事件循环里的 epoll 立刻返回，主线程就知道"有活干了"。相比信号，它不丢事件、不会打断系统调用、不需要处理EINTR。相比管道，它只用一个 fd，且读写都是 8 字节定长，语义清晰。

timerfd把定时器也变成了 fd。timerfd_create加timerfd_settime，到点了那个 fd 变成可读，读出来的是"超时了几次"。这样你的 epoll 循环可以统一处理"网络事件、信号、定时器"三类输入，不用再纠结"epoll_wait 的 timeout 该设多少"这种问题。我在写高精度定时任务时基本都会用 timerfd 替代setitimer，因为它能正确处理系统时间被调整的情况（可以选择用CLOCK_MONOTONIC）。

memfd_create则是创建一个纯内存的匿名文件，有 fd 但不在文件系统里可见。它最大的用途是跨进程传递大块内存：一个进程创建 memfd 并mmap写入数据，然后通过 UDS 把这个 fd 用SCM_RIGHTS传给另一个进程（sendmsg附带辅助数据），对方recvmsg拿到 fd 之后直接mmap，数据一次都没被拷贝。这是容器和云原生场景里很经典的一种 IPC 模式。

6.4 什么时候才轮到TCP出场

上面这些机制都限定在同一台机器内。一旦需要跨主机，选择就收敛到 TCP 或者更上层的消息中间件了。这时候要考虑的就不是"哪种 IPC 快"，而是序列化格式、重连策略、超时重传、消息幂等等网络层问题——这些在本地 IPC 里基本不存在，因为本地通信不会遇到网络分区和丢包。

我一般的判断是：先默认本地 IPC，只有在明确需要分布式部署时才上网络层。反过来做的人，往往会为了一台机器上的两个进程搭一套完整 RPC，增加了运维复杂度和故障点，而收益接近于零。

7. 选型对照表与排查手段

7.1 按场景挑工具

把前面讲的东西汇总成一张表，这是我实际做架构设计时会对照的：

一个常见的误区是"越复杂的机制越高级"。实际上管道解决不了的问题，共享内存往往能解决，但共享内存引入的同步复杂度可能远超收益。我做过一个项目，两个进程之间每秒传几十条小消息，最开始用了共享内存加互斥锁，代码三百多行还是偶尔出锁问题；后来换成SOCK_SEQPACKET的 UDS，代码缩到一百行出头，性能完全够用，稳定性反而上来了。在满足性能要求的前提下，永远选语义最简单的那一个。

7.2 组合拳：共享内存加eventfd的实用搭配

共享内存配信号量是经典组合，但信号量有个小缺点：每次sem_post/sem_wait都可能陷入内核。如果你只需要单向的"数据就绪"通知，eventfd更轻。我的常用组合是这样：

• 共享内存放数据缓冲区，用环形队列的结构。
• 生产者写完，往eventfd写一个计数。
• 消费者epoll_wait收到事件，读eventfd，然后从共享内存取出数据。

这个组合的好处是消费者可以完全挂在事件循环里，不需要额外的消费者线程去阻塞等待。环形队列的读写指针必须是原子的，uint64_t在 64 位平台上天然原子；如果要用 32 位平台，得用__atomic系列内建函数。

环形队列有个必须处理的边界：缓冲区满了怎么办。生产者不能覆盖未消费的数据，所以要么阻塞等待，要么丢弃，要么扩容。这三者对应完全不同的业务语义，必须在设计阶段想清楚，而不是留到线上出问题时临时决定。

7.3 排查IPC问题的三板斧

本地 IPC 出问题时，我通常按这个顺序排查：

第一板斧，看对象存不存在。ipcs -m（共享内存）、ipcs -q（消息队列）、ipcs -s（信号量）、ls -l /dev/shm/、ls -l /dev/mqueue/。如果对象不在了，说明程序崩了没清理，或者创建的权限不对。

第二板斧，看fd和进程。lsof -p <pid>看进程打开了哪些 fd，管道和 socket 都能看出来；ls -l /proc/<pid>/fd/更直接，管道会显示成pipe:[12345]，两个进程如果指向同一个 inode 号，那就是同一根管道。这个技巧在确认"谁继承了不该继承的 fd"时特别好用。

第三板斧，看系统调用。strace -f -e trace=read,write,openat,mmap,clone把整个进程树的行为打出来，卡在哪个调用上一目了然。我开头那个管道阻塞问题，就是靠strace看到"两个进程都在 read，没有任何写操作"才锁定了方向。注意-f一定要加，否则子进程的系统调用看不到。

还有一个容易被忽略的点：IPC 对象的权限受 umask 影响。你用0666创建共享内存，如果进程的umask是022，最终权限就是644，别的用户组的进程打不开。这类问题在单机测试时永远不会出现，一到多用户环境就冒出来。稳妥的做法是显式umask(0)之后再创建，或者创建后用fchmod校正。

8. 我在多进程项目里被反复教育过的几件事

8.1 fork之后fd的继承是新手的头号陷阱

这是我最想强调的一点。fork()出来的子进程会继承父进程所有没有O_CLOEXEC的 fd，包括管道、socket、eventfd、共享内存的句柄。这些继承的 fd 会让引用计数始终保持为正，导致 EOF 永远不来、socket 永远不关闭、资源永远不会被回收。更要命的是这种 bug 往往不报错，只是"行为不符合预期"，排查成本极高。

我的做法是三条一起上：一是创建 fd 时无脑加O_CLOEXEC；二是 fork 之后立即关闭子进程不需要的 fd，不要嫌麻烦；三是在exec之前把不需要继承的 fd 全部关掉。第三点在写一些嵌入式或者容器化的启动器时特别重要。

8.2 崩溃后的残留必须由启动流程兜底

任何依赖"干净退出"的 IPC 清理逻辑都是不可靠的，因为进程可能被kill -9、可能段错误、可能被 OOM killer 干掉。启动时清理残留、运行中定期检查、退出时尽力清理——这三层里，第一层才是真正有效的。

具体做法：共享内存在创建前先尝试shm_unlink一次（忽略ENOENT）；UDS 和 FIFO 在bind/mkfifo之前先unlink，并对失败情况做容错；命名信号量同理。这样即使上次是崩溃退出，本次启动也能拿到干净的状态。但要注意多实例场景：如果两个实例同时启动，互相unlink对方的东西，就会出事。这时候需要一个基于文件锁或者目录的互斥机制来串行化初始化。

8.3 一个关于心态的体会

写了这么多年多进程程序，我越来越觉得 IPC 的难度不在 API 本身——pipe、mmap、socket这些调用的用法半小时就能学会。难的是把并发时序想清楚。哪些操作必须原子、哪些状态可能不一致、对方在你操作的间隙死掉了怎么办、消息发出去之后多久没回应算超时——这些问题没有银弹，只能一个一个地在设计阶段穷举。

我的习惯是：设计 IPC 协议时先画一张时序图，标出每个可能被信号打断的点、每个可能失败的调用、每个可能残留的对象，然后针对这些点逐个决定策略。看起来很啰嗦，但比起在生产环境里用通宵排查一个偶发的死锁，前期的这点投入实在划算。

如果只能从这篇里拿走一句话，那就是：先想清楚同步和失败处理，再挑通信机制。顺序反了，选什么工具都会踩坑。