fork 之后为什么需要 IPC这篇笔记专门解答一个问题父进程fork出子进程后两者明明长得一样为什么一转身要通信就变麻烦了IPC 到底是干嘛用的关联文档[[进程间通信方式详解-IPC]]各 IPC 方式的速查表一、先把场景还原那段话在说什么原文那段话的意思拆开看是两层第一层fork 时父进程fork子进程的那一刻子进程是父进程内存映像的复制件。父进程手里打开着的那些文件描述符File Descriptor简称 fd会连同状态一起被复制到子进程里。所以 fork 完成的瞬间父子俩天然就共享着同一批打开的文件/管道/socket——这叫继承。第二层fork 后但 fork 这个动作只有一次是一次性复制。等父子各自跑起来之后父进程新生成的数据、子进程新算出来的结果就不在对方的地盘里了。这时候想让一方把信息告诉另一方就得主动用一套通信机制——这就是IPCInter-Process Communication进程间通信。一句话总结那段话fork 的继承是一次性赠礼fork 之后的交流必须靠IPC 持续传话。二、为什么 fork 之后不能直接读对方的内存这是理解 IPC 存在意义的核心。1. 每个进程有自己独立的地址空间Linux 下每个进程都活在自己的虚拟地址空间里。进程 A 的0x7ffe...这块内存和进程 B 的0x7ffe...虽然地址数字一样但指向的物理内存是两码事。进程之间默认是内存隔离的——A 不能直接指针解引用去读 B 的变量。这是操作系统的保护机制否则一个进程写错了地址就能把别人搞崩整个系统乱套。2. fork 的复制是一次性的fork()调用时子进程把父进程当时的内存抄了一份写时复制 COW先不深究。之后两边各干各的fork() 瞬间 父进程 count 100 ──复制── 子进程 count 100 ✅ 一样 fork() 之后 父进程处理请求count 变成 150 子进程处理请求count 变成 80 ❌ 各走各的互不可见父进程想知道子进程到底处理了几个请求没法直接去读子进程的count——它读到的永远只是自己那份。3. 所以需要一个中间地带让两边都能碰既然直接读对方内存不行那就让父子俩都能访问的第三方通道来传话一方把数据写进通道另一方从通道里读出来。这个通道就是IPC。它本质上是操作系统提供的一块/一条双方都能访问的中介绕开了进程间的内存隔离。三、IPC 到底是干嘛用的——一句话定义IPCInter-Process Communication进程间通信 操作系统提供的一套机制让独立的进程之间能够交换数据、传递消息、协调动作。它要解决的就三件事需求举例传数据子进程把自己处理的请求数告诉父进程传消息/事件一个进程通知另一个我干完了同步互斥多个进程抢着写同一份共享数据时排队、加锁原文里子进程在 close 之前告诉父进程自己处理了多少个请求以支撑父进程全局统计就是典型的传数据需求。四、回到原文那个具体例子“子进程需要在 close 之前告诉父进程自己处理了多少个请求以支撑父进程进行全局的统计。”把它画成时序父进程 子进程 | | |--- fork() -----------------| (继承父的 fd一次性) | | | 各自干活各自计数 | | parent_count 处理量 | child_count 处理量 | | | | 即将 close() 退出 | | | [IPC 传话] | 子进程把 child_count 发给父进程 | | | total parent_count | | 收到的 child_count | | X 子进程 close 退出 | 打印全局统计那条[IPC 传话]的线必须由你主动建立——fork 不会帮你搞定。常见做法fork之前就先建好一根匿名管道pipefork 后父关写端、子关读端子进程把计数 write 进去父进程 read 出来或者用共享内存 信号量或者子进程退出时把状态塞进exit(status)父进程wait()回收时读到但这种方式只能传一个 8 位整数信息量极小。这就解释了那段话的后半句“子进程和父进程必须采用 IPC 方案来传递信息”——不是 fork 不给力而是 fork 之后两边已经各跑各的要持续传话就得另搭 IPC。五、顺便厘清fork 时继承文件描述符是怎么回事很多人把fork 时继承 fd和IPC搞混其实它们是两回事1. fd 是什么fd文件描述符就是一个小整数0、1、2、3…是进程访问已打开文件/管道/socket的句柄。每个进程有一张自己的 fd 表进程的 fd 表每个进程一份 fd 0 - stdin fd 1 - stdout fd 2 - stderr fd 3 - 某个打开的文件 / 管道 / socket ...2. fork 时发生了什么fork 复制父进程时把这张 fd 表也复制了一份给子进程。更关键的是fd 指向的那个打开文件对象内核里的 struct file是同一份——父子俩的 fd 3 指向同一个东西。内核中打开文件对象共享 ┌──────────┐ 父进程 fd 3 ──┤ 同一个 ├── 子进程 fd 3 └──────────┘所以如果 fork之前父进程已经打开了一个文件/socketfork 后子进程自动也能用——这是继承不需要你做任何 IPC。但注意这是共享一个已打开的东西不是新建一条通信通道。而且它只在 fork 那一刻发生。3. 一个经典用法fork 前先建管道正因为fork 会继承 fd所以利用这个特性做父子通信的标准套路是// 1. fork 之前先建管道此时只有父进程有这对 fdintpipefd[2];pipe(pipefd);// pipefd[0]读端, pipefd[1]写端// 2. forkpid_tpidfork();if(pid0){// 子进程想写给父进程就关掉自己的读端close(pipefd[0]);intcount处理了多少请求();write(pipefd[1],count,sizeof(count));close(pipefd[1]);_exit(0);}else{// 父进程想读子进程的就关掉自己的写端close(pipefd[1]);intchild_count;read(pipefd[0],child_count,sizeof(child_count));// 拿到了做全局统计}这段代码完美呼应原文子进程在 close 之前用管道把处理了多少个请求告诉父进程。管道就是这里用到的 IPC。六、IPC 的常见方式聚焦为什么用、用在哪)完整对比表见 [[进程间通信方式详解-IPC]]这里只讲每种解决什么问题帮你建立直觉。1. 管道Pipe——最贴原文场景是什么内核里的一段缓冲区一头写一头读单向。匿名管道只能给有亲缘关系父子的进程用——正好就是原文 fork 场景。命名管道 FIFO有名字无亲缘关系的进程也能用。适用父子之间传少量结构化/流式数据正是原文例子的首选。2. 信号Signal——只够拍一下肩膀是什么异步通知比如kill -9、CtrlC。特点只能传一个编号传不了数据。适用通知该停了“出事了”不适合传处理了多少请求这种带内容的。3. 消息队列Message Queue——带结构、能排队是什么内核维护的消息链表进程往里塞消息、另一进程取有类型、能按顺序。适用多个进程之间发结构化消息比管道灵活。4. 共享内存Shared Memory——最快但要自己加锁是什么把同一块物理内存映射到多个进程的地址空间大家直接读写同一块内存。最快没有内核态/用户态来回复制。代价多个进程同时写会打架必须配合信号量做互斥。适用大数据量、高频交换——比如数据库共享缓冲区。5. 信号量Semaphore——不传数据只管排队是什么一个计数器 PV 操作用来做同步/互斥。适用配合共享内存防止多方同时写坏数据。原文没直接提但只要用共享内存就绕不开它。6. 套接字Socket——本地跨机通吃是什么基于网络协议TCP/UDP的 IPC能跨主机。适用分布式系统、不同机器上进程通信。本机也能用Unix Domain Socket比网络 socket 快。七、一张图收束全文┌─────────────────────────────────────┐ │ fork() 瞬间 │ │ 子进程继承父进程的 fd 表一次性 │ │ → 这部分共享已打开的东西不用 IPC │ └───────────────┬─────────────────────┘ │ fork 之后父子各跑各的 内存隔离互不可见 │ ┌───────────────────┴───────────────────┐ ▼ ▼ 想传数据/通知/同步 不需要交流 必须主动搭 IPC 通道 各自收工 │ ┌────────┼────────┬──────────┬─────────┐ ▼ ▼ ▼ ▼ ▼ 管道 信号 消息队列 共享内存 Socket (父子) (拍肩膀) (带结构) (最快锁) (跨机) ▲ └─ 原文例子子进程把处理了多少请求通过管道告诉父进程八、对应到 Java / 后端开发原文是 C/Unix 视角Java 后端实际很少手写 forkpipe。但理解它有用原文概念Java/后端里的对应物fork 出多进程JVM 多进程部署、ProcessBuilder启动子进程子进程结果回传父进程子进程写 stdout父进程读取或走 HTTP/RPC 回报管道/消息队列Kafka / RabbitMQ / RocketMQ跨进程传消息的主力共享内存MappedByteBuffermmap少见SocketNetty / gRPC / Dubbo / HTTP跨进程通信的绝对主力信号量/同步Redis / ZooKeeper 分布式锁后端现实跨进程通信基本被RPCDubbo/gRPC 消息队列Kafka包揽了。forkpipe 这种底层 IPC多半是操作系统、容器运行时、Nginx 这类基础设施在用业务代码很少直接碰。但搞懂它能帮你理解 Nginx 的 worker 进程模型、Redis 的 forkbgsave、各类多进程架构为什么那么设计。九、一句话记住fork 的继承是一次性赠礼IPC 是持续传话的电话线。子进程 fork 出来那一刻手里有父进程给的 fd但等它跑起来算出结果要把结果告诉父进程时就得另拉一条 IPC 电话线管道/共享内存/socket…因为进程之间默认内存隔离、互不可见。参考原文链接https://blog.csdn.net/weixin_43924419/article/details/143274807关联笔记[[进程间通信方式详解-IPC]]、[[SMP-NUMA-MPP三种多处理器架构详解-与Java开发的关系]]