进程之间如何通信？

核心回答

不同进程通常有独立的虚拟地址空间，不能直接把自己的普通内存地址交给另一个进程使用。进程间通信（IPC）需要通过受控的数据传递或共享映射，并处理访问顺序和权限。

以 Linux 常见机制为例：

• 管道与 FIFO：通过内核缓冲区传字节流。匿名管道常由父进程创建后让子进程继承；FIFO 有路径名，无亲缘关系的进程也可按权限打开。双向通信通常用两条管道。
• 消息队列：进程按一条条消息发送和接收，保留消息边界，适合控制命令、任务通知等，但有消息大小和队列容量限制。
• 共享内存：把同一块内存映射到多个进程，适合本机大量数据交换，减少反复经内核缓冲区搬运数据的开销；读写同步需要另外设计。
• 信号：通知进程某个事件发生，例如请求退出或子进程状态变化，适合少量控制信息。
• 信号量、进程间互斥锁等：主要协调访问顺序和资源占用，通常配合共享数据使用，并不负责承载大块业务数据。
• Socket：本机可用 Unix Domain Socket，跨机器可用网络 Socket；适合服务之间的双向请求/响应，是否保留消息边界取决于具体类型。

选择时看通信范围、数据量、消息边界和同步要求：简单父子进程流水线可用管道，本机服务交互可用 Unix Domain Socket，大数据交换可用共享内存加同步，跨机器则通过网络协议通信。

管道和消息队列有什么不同？

管道传的是连续字节，写端写了几次，不保证读端就能按同样次数读到对应消息。应用需要按长度、分隔符等协议还原消息。消息队列则以消息为单位，但仍要约定消息格式、版本和接收规则。

两者都受容量约束。管道空时阻塞读取会等待，有写者且暂时没数据时，非阻塞读取可返回暂不可读；管道满时写入也可能等待或失败。消息队列满、对端变慢，同样需要明确等待、限时失败或其他处理，不能无限堆积。

FIFO 的文件路径只是找到通信对象的入口，数据不因为有文件名就被写到磁盘里。这里的消息队列主要指 POSIX/System V 等操作系统 IPC 队列，也不能直接套用 Kafka 那类消息中间件的持久化、消费组和跨机器复制能力。

为什么共享内存还需要同步？

共享映射只解决“能访问同一份数据”，不会替应用安排“什么时候可以读”。例如 A 向共享缓冲区写一条记录，若还没写完就更新了“可读”状态，B 可能读到半条记录；两个进程同时修改计数，也可能互相覆盖。

因此，需要支持跨进程的互斥锁、信号量等机制，或者经过正确设计的原子操作和发布顺序，保证写入完整、可见之后再通知对方读取。阻塞等待、唤醒和进程异常退出后的恢复也要考虑。用普通变量反复轮询，并不能自动保证这些性质。

共享区域在不同进程中的虚拟地址还可能不同，所以内部数据常保存偏移量或索引，不能随意保存只在某个进程内有效的指针。共享内存的实际性能仍受锁竞争、缓存一致性和数据布局影响，不能只凭“少拷贝”断言所有场景最快。

能用一个实际场景说明吗？

本地 MCP stdio 工具可以作为父子进程通信的例子：应用启动工具子进程，把请求写入它的标准输入，从标准输出读取回复。底层可以用两条单向管道组成双向交互，双方再按应用协议识别完整消息。

如果工具独立运行并要服务多个进程，可改用本机 Socket 或 HTTP 服务；如果进程需要交换大量图像或数组，也可以用消息通道传任务和数据位置，把大块内容放在共享内存里。数据通道与通知机制可以组合，不必把所有内容都放进同一种 IPC。

常见追问

为什么子进程结束后，管道读取还可能一直等？ 读端只有在所有写端引用都关闭后，才会读到 EOF。父子进程继承文件描述符后，应关闭各自不需要的端；其他进程如果仍持有写端，也会影响结束判断。

用了 IPC，业务处理就可靠了吗？ 传到对方不等于业务已完成。需要可靠请求/响应时，还应设计超时、结果确认及重复请求处理；不同机制的容量、对象生命周期和进程退出后的清理规则，也要分别管理。

对应教程

参考资料