Linux 进程间通信之管道：从 pipe() 的内核语义到 FIFO 落地排错

多进程协作时，数据该走哪条路？管道是 Linux 给出的最朴素答案：shell 里一个竖线 |、C 代码里一次 pipe()，背后都是同一套机制。但真正上手写多进程程序时，很多人会遇到「读端永远阻塞不返回」「子进程读不到任何数据」「写着写着收到 broken pipe」这类诡异问题。

问题的根源通常不是 API 用错，而是对管道的内核语义理解不足：它本质上是一块内核缓冲区加两个文件描述符，方向单一、靠引用计数判断结束、靠阻塞控制节奏。只记住「pipe 创建一对 fd」这两行用法，一旦进程关系变复杂（fork、exec、后台进程），就会踩到 fd 继承带来的坑。

本文分享一套把管道写对、写稳的完整方法：内核模型 + 关端规则 + 阻塞/EOF 语义 + 排错清单，所有示例均可直接编译运行。

一、IPC 家族里的管道：匿名与 FIFO 的分工

先给管道定个位：Linux 的进程间通信不止一种，管道只是其中最轻量的一种。

匿名管道 ：用 pipe() 创建，只在有亲缘关系的进程（父子、兄弟）之间可用，进程退出即消失。
命名管道（FIFO） ：用 mkfifo 在文件系统里留下一个 p 类型节点，任意进程只要能打开它就能通信。
共同点 ：两者都是单向字节流，没有消息边界，读写方式与普通文件几乎一致。
定位：适合传递「流式数据」；若需要双向或消息结构化，应转向套接字或消息队列。

**核心结论：**先判断进程有无亲缘关系，再决定用匿名管道还是 FIFO，这一步选错后面全是补丁。

二、pipe() 到底创建了什么：内核缓冲与两个 fd

理解管道的第一步：看清 pipe() 返回的到底是什么。

一块内核缓冲区：默认 65536 字节的环形缓冲，数据写进去后由内核保管，与用户空间无关。
两个文件描述符 ：fd[0] 固定为读端（只读），fd[1] 固定为写端（只写），方向在创建时就定死了。
退化风险 ：如果在同一个进程里既写 fd[1] 又读 fd[0]，管道会退化成「自我通信」，通常没有意义。

下面这段代码在单进程内演示一次最简单的写读往返，可直接用 gcc pipe_demo.c -o pipe_demo 编译：

c 复制代码

#include <stdio.h>
#include <unistd.h>
#include <string.h>

int main(void) {
    int fd[2];
    char buf[64] = {0};
    if (pipe(fd) == -1) { perror("pipe"); return 1; }

    const char *msg = "hello pipe\n";
    write(fd[1], msg, strlen(msg));    /* 写端 */
    read(fd[0], buf, sizeof(buf) - 1); /* 读端 */
    fputs(buf, stdout);

    close(fd[0]);
    close(fd[1]);
    return 0;
}

要点：fd[0] 只读、fd[1] 只写，数据存放在内核缓冲区而非用户内存。

三、fork 之后必须关端：单向数据流的正确姿势

真正用管道传数据，一定发生在 fork 之后，而 fork 会把 fd 复制一份给子进程。

必须关掉不用的一端 ：父进程要写就关 fd[0]，子进程要读就关 fd[1]，否则两端永远有持有者。
不关端的后果 ：父进程 read 等不到 EOF（返回 0），因为它自己还握着写端，内核认为「还有人可能写」。
exec 场景加重 ：exec 会保留未标注 FD_CLOEXEC 的 fd，子进程里残留的写端同样会让父进程卡在读上。

下面这段是「父写子读」的标准模板，配合 fork 与文件拷贝使用：

c 复制代码

int fd[2];
if (pipe(fd) == -1) return -1;
pid_t pid = fork();
if (pid > 0) {
    close(fd[0]);                       /* 父亲关读端 */
    while ((n = read(src, buf, sizeof buf)) > 0)
        write(fd[1], buf, n);
    close(fd[1]);                       /* 写完关写端，子进程才能读到 EOF */
    waitpid(pid, NULL, 0);
} else if (pid == 0) {
    close(fd[1]);                       /* 子进程关写端 */
    while ((n = read(fd[0], buf, sizeof buf)) > 0)
        write(dst, buf, n);
    close(fd[0]);
}

核心结论：数据流向靠「关端」而非靠代码约束，漏关一端 = 永久阻塞的隐患。

四、管道容量与阻塞：PIPE_BUF 和写满之后发生什么

管道不是无限大的，写满和读空都会改变进程状态，这是所有阻塞问题的根源。

常量 / 属性	典型值	含义
`PIPE_BUF`	4096	小于等于它的一次写入是原子的，不会与其他进程写穿插
管道容量	65536	内核缓冲区默认大小，可用 `F_SETPIPE_SZ` 调整
读端读空（阻塞模式）	挂起	等待写端写入数据
写端写满（阻塞模式）	挂起	等待读端消费数据
任一操作（`O_NONBLOCK`）	`-1` + `EAGAIN`	立即返回，由调用方自行重试

原子性红利 ：多个进程同时往同一管道写小块数据时，只要不超过 PIPE_BUF，内容不会被切碎混杂。
非阻塞的用法 ：给管道 fd 加 O_NONBLOCK 后，可以把它塞进 select/poll/epoll 事件循环，避免线程卡死。
容量的调法 ：fcntl(fd, F_SETPIPE_SZ, 128 * 1024) 可扩大缓冲，减少大数据量下的读写互等。

核心结论：阻塞是特性不是 bug，先想清楚「等谁」，再决定用阻塞还是非阻塞。

五、读到 0 才算结束：管道 EOF 的触发条件

很多 bug 的表象是「读不到结束」，本质是 EOF 条件没被满足。

EOF 的唯一触发点 ：管道写端的所有文件描述符都已关闭 ，此时读端 read 返回 0。
常见误解 ：以为「数据读完就返回 0」。实际上缓冲区读空后如果没有写端关闭，read 只会阻塞等待。
SIGPIPE 的来源 ：写端发现读端已全部关闭，向写进程发送 SIGPIPE，默认动作是终止进程；忽略它则写操作返回 -1 并置 EPIPE。
验证手法 ：用 lsof | grep pipe 或 /proc/<pid>/fd 查看还有哪些进程握着管道端点，一眼定位漏关的 fd。

核心结论：read == 0 读到的不是「数据没了」，而是「所有写端都没了」。

六、mkfifo 打通无亲缘进程：命名管道落地

当两个进程毫无血缘关系（比如一个守护进程 + 一个运维脚本），就轮到 FIFO 出场。

创建节点 ：mkfifo /tmp/ipc.fifo，文件类型显示为 p，权限与普通文件一样可管控。
打开语义 ：默认 open 会阻塞直到另一端也打开，读写双方必须一先一后都能进来。
非阻塞技巧 ：open(path, O_RDWR | O_NONBLOCK) 可避免「只有写者没有读者」时无限等待，本机自环读写也成立。

下面用一段 C 代码扮演「命令接收端」，从 FIFO 里循环读取上游进程发来的指令：

c 复制代码

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>

int main(void) {
    mkfifo("/tmp/ipc.fifo", 0666);
    int fd = open("/tmp/ipc.fifo", O_RDONLY | O_NONBLOCK);
    if (fd < 0) { perror("open"); return 1; }

    char buf[256];
    ssize_t n;
    while ((n = read(fd, buf, sizeof buf)) > 0)
        fwrite(buf, 1, n, stdout);   /* 处理上游发来的指令 */

    close(fd);
    return 0;
}

要点：FIFO 把「进程关系」换成了「路径约定」，谁有路径谁就能接入。

七、Shell 管道串流水线：grep、awk 与 sed 的组合

管道最日常的用法其实在 shell 里，| 的本质就是自动创建管道并把前一个命令的 stdout 接到后一个命令的 stdin。

自动关端：shell 已替你处理好 fork、fd 继承与关闭，这也是命令行不容易踩坑的原因。
单竖线与双竖线 ：| 是管道（传递数据），|| 是逻辑或（判断退出码），不要混淆。
tee 的分流 ：cmd | tee full.log | grep ERROR 能一边落盘一边过滤，是日志排查利器。

下面这段命令把内核日志按模块过滤、计数、再落盘，完整演示一条 shell 流水线：

bash 复制代码

# 统计内核日志里各模块的告警条数，并保留完整过滤结果
journalctl -k -o cat 2>/dev/null | grep -Ei 'warn|error' \
  | awk '{print $3}' | sort | uniq -c | sort -rn > top_modules.txt

# 双管道分流：既保存全量，又实时看错误行
dmesg -w | tee dmesg_full.log | grep --line-buffered -i error

核心结论：Shell 管道 = 匿名管道的语法糖，理解 fd 规则后你也能手写出同样稳健的 C 版本。

八、九成管道 bug 都在这：阻塞与卡死排查表

遇到管道问题别乱改代码，先按症状对号入座，多数情况三分钟能定位。

症状	常见原因	处理办法
`read` 永远阻塞、不返回 0	有进程（含 exec 后的子进程）仍持有写端	关闭多余 fd，或设 `FD_CLOEXEC`
子进程读到空数据	父进程未关闭读端，写入被自己缓冲	fork 后立即关掉不用的一端
写到一半卡死	缓冲区写满且读端消费慢	扩大 `F_SETPIPE_SZ` 或加快读端
收到 `SIGPIPE` 被杀	读端已全部退出	忽略 `SIGPIPE` 并处理 `EPIPE`
`mkfifo` 的 `open` 卡住	只有一端打开，另一端迟迟不来	用 `O_RDWR

排查顺序建议按这条链走：

确认 fd 数量 → 检查持有端进程 → 观察阻塞位置 → 加非阻塞或超时复现

核心结论：管道问题 90% 出在「谁还握着哪一端」，先查 fd 再查逻辑。

九、选型不纠结：管道与四种 IPC 的能力对比

管道不是万能的，把它放进 IPC 家族里横向比一比，选型就有依据了。

机制	方向	进程关系要求	数据模型	典型场景
匿名管道	单向	必须亲缘	无边界字节流	父子协作、shell 重定向
FIFO	单向	任意进程	无边界字节流	守护进程指令通道、日志管道
System V 消息队列	双向	任意进程	有边界消息	结构化小消息、多消费者
共享内存	双向	任意进程	原始内存	大数据量、要求零拷贝
Unix 域套接字	双向	任意进程	字节流/数据报	本机 RPC、可传 fd 与凭证

要简单就选管道：无需额外初始化，进程退出自动回收，几乎零学习成本。
要速度就选共享内存：但必须自备同步（信号量、文件锁），否则数据会乱。
要双向且结构化就选 Unix 域套接字 ：既能传字节，也能借助 SCM_RIGHTS 传递文件描述符。

核心结论：单向流式数据用管道，跨进程双向或大数据量再升级，别一开始就上重武器。

十、实战：用管道做多进程日志清洗流水线

最后把前面所有知识点串成一个可运行的场景：采集 → 清洗 → 统计三段式流水线。

采集端：持续把原始日志写入第一个 FIFO，扮演生产者。
清洗端：从 FIFO 读出，过滤掉 DEBUG 行后写入第二个 FIFO，扮演加工者。
统计端：从第二个 FIFO 读取，实时统计 ERROR 计数，扮演消费者。

启动与验证只需三行命令，注意顺序「先起读端、再起写端」可避开 open 阻塞：

bash 复制代码

mkfifo /tmp/f1 /tmp/f2
# 三个终端分别启动，读端先行
while read -r line; do grep -v DEBUG <<< "$line" > /tmp/f2; done < /tmp/f1   # 清洗端
while read -r line; do [[ $line == *ERROR* ]] && echo "$line"; done < /tmp/f2 # 统计端
for i in $(seq 100); do echo "2024-06-01 job$i ERROR: demo" > /tmp/f1; done  # 采集端

这段代码做的事：采集端写入一百行混杂日志，清洗端去掉 DEBUG 行，统计端只输出含 ERROR 的行，三者各自独立、靠 FIFO 解耦。

要点：FIFO 串成流水线后，任一环节可单独重启，这正是管道解耦的价值。

结语

管道是 Linux 里最容易上手、也最容易写错的 IPC：API 只有 pipe、mkfifo 两个入口，但真正决定成败的是 fork 之后的关端纪律 、对阻塞与 EOF 语义的准确把握，以及面对卡死症状时「先查 fd、再查逻辑」的排查习惯。把本文的模板和排查表放进你的工具箱，匿名管道与 FIFO 就再也不会是玄学。

记住一句话：管道里流动的不只是数据，还有你对 fd 引用计数的掌控力。