想象你走进一栋写字楼：每个部门（进程）都拥有一间独立办公室，里面有自己的文件柜（私有地址空间）。你永远不能直接闯进隔壁办公室翻人家的文件——这就是操作系统最底层的“隔离”规则。但公司要运转，部门之间必须协作：工程部要把图纸交给市场部，财务要把账单发给法务。怎么办呢？只能借助楼里的公共设施：各层之间的传送带（管道）、前台代收信件（消息队列）、走廊里的公共白板（共享内存）、会议室门口的数字门牌（信号量），以及可以打给分公司同事的电话线（套接字）。而楼宇管理处（内核）负责安装这些设施、查验每个人的工牌（权限校验），并在需要时替你把文件从一间办公室搬到另一间。本文就用这栋写字楼的故事，把进程间通信（IPC）的六种主流方式一次讲透。

岗位关联

对 AI 从业者而言，理解 IPC 是排查模型训练卡顿、设计多进程数据管道、优化分布式推理服务的前提——你不会想因为一次拷贝的浪费，让 GPU 白白等待几秒。

目录
  1. 可视化演示
  2. IPC基本模型
  3. 管道通信
  4. 消息队列
  5. 共享内存
  6. 信号量机制
  7. 套接字通信
  8. 综合对比
  9. 工程实战
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态展示操作系统进程在就绪、运行、等待、终止四种状态间的转换过程，支持步进控制与自动播放。

本节配有交互动效（进入视口后自动加载，约 3KB）。

进程状态转换 就绪态：进程已具备运行条件，等待CPU分配 运行态：进程正在CPU上执行 就绪 → 运行 → 等待 → 就绪 进程在生命周期中反复进行状态转换

IPC基本模型

写字楼刚建成时，每间办公室都装着一扇厚重的防盗门。门后是独立的文件柜，走廊尽头是楼宇管理处——内核对所有办公室的“内部构造”了如指掌，但绝不会让财务部的员工直接跨进工程部翻图纸。这就是第一章规则：进程拥有独立的虚拟地址空间，页表各不相同，A 进程的指针在 B 进程眼里只是毫无意义的数字。既然直接访问走不通，“通信”就必须绕道管理处备案过的公共设施。

要协作，业界提炼出两种通信模型。一种叫“消息传递”：A 把文件装进信封，交给管理处，管理处验完工牌后把信投递到 B 的信箱——管道、消息队列、套接字都属此类。另一种叫“共享内存”：管理处把走廊尽头一间空屋子划为公共白板，通知 A 和 B 都能进来写画，此后双方直接在白板上交流，管理处不再逐字搬运。两种模型的差别，本质上是“每次通信都要找管理处”和“一次申请、长期直用”的差别。

消息传递尽管安全、规范，但每一次读写都要跨界一次：数据先从用户区拷进内核缓冲区（copy_from_user），再由内核拷进对方的用户区（copy_to_user）。共享内存则在建立映射后，读写就是普通内存指令，省去了这两次搬运。于是成本模型可以写为：

回到写字楼：管理处偶尔帮你传话，安全可靠但慢；白板直写没有搬运费，却容易互相涂改。理解了这副图景，后面每一种 IPC 都是在“信任成本”和“协作效率”之间做取舍。

Tmsg=2×Tcopy+Tsyscall,Tshm=Taccess+Tsync\displaystyle T_{\text{msg}} = 2 \times T_{\text{copy}} + T_{\text{syscall}}, \qquad T_{\text{shm}} = T_{\text{access}} + T_{\text{sync}}
  1. T_msg 消息传递总开销指一次消息传递从发送方到接收方的总时间成本，包括两次数据拷贝和一次系统调用。
    Tmsg=2×Tcopy+Tsyscall\displaystyle T_{\text{msg}} = 2 \times T_{\text{copy}} + T_{\text{syscall}}
  2. 两次 T_copy 的含义第一次拷贝是“用户态 → 内核态缓冲区”，第二次是“内核态缓冲区 → 接收方用户态”，数据每过一次边界都要付搬运费。
    2×Tcopy\displaystyle 2 \times T_{\text{copy}}
  3. T_syscall 系统调用开销内核介入需要切换 CPU 特权级（用户态 ↔ 内核态），这部分时间不可忽略，频繁小消息时尤其昂贵。
    Tsyscall\displaystyle T_{\text{syscall}}
  4. T_shm 共享内存开销映射建好后，读写共享区只是普通内存访问；但多个进程同时改写会有竞态，必须额外支付同步成本 T_sync。
    Tshm=Taccess+Tsync\displaystyle T_{\text{shm}} = T_{\text{access}} + T_{\text{sync}}

管道通信

两个相邻的办公室在墙上打通一根粗管，管口装好入料嘴和取料口——这就是管道。规矩很简单：数据只朝一个方向流，投进去的字节按顺序滚出来，管道满了，投料的人就得端着文件站在原地等；管道空了，取料的人也得干等着。这样的设施在 Linux 里叫匿名管道（pipe），由 pipe() 系统调用创建，返回两个文件描述符：一个写端、一个读端。因为文件描述符随着 fork() 被子进程复制，所以匿名管道天然服务于父子进程或兄弟进程之间。

如果想让整栋楼任意两间办公室都能接管道，就得用命名管道（FIFO）。它像一个挂在楼道里的特殊“水管文件”（mkfifo 创建），任何进程只要打开同一个 FIFO 文件就能接上同一根管子使用。和匿名管道一样，它传输的是无结构的字节流：没有“信封”、没有消息边界，你写 100 字节、对方可能一次读到 20 字节，也可能一次读到 80 字节，读多少完全由内核决定。

内核为管道维护一个有界环形缓冲区（经典实现约 64 KB）。写进程调用 write 时，内核检查空闲空间是否足够，不够就把写进程挂起；读进程读取后腾出空间，再唤醒等待中的写进程。若读端全部关闭，缓冲区不再被消费，写进程继续写入会收到 SIGPIPE 信号而终止。判断“是否阻塞”的条件可写成：

传送带的隐喻贯穿始终：管道是廉价、快速的一次性输运通道，适合“流水线式”单向数据流，但它的缺点也很明显——双向通信需要建两根管子，且数据一旦被读走就不复存在，无法存档。

block_writeriffavail<n\displaystyle \text{block\_writer} \quad \text{iff} \quad \text{avail} < n
  1. avail 空闲空间表示管道缓冲区当前还能容纳的字节数，它会被写操作扣减、被读操作释放。
    avail\displaystyle \text{avail}
  2. 请求字节数 n写进程本次希望写入的数据量，内核不能只写一半就假装成功，要么满足、要么阻塞。
    n\displaystyle n
  3. block_writer 阻塞写者当空闲空间小于请求量时，写进程进入睡眠等待，直到读取方腾出地方后再被唤醒。
    block_writeriffavail<n\displaystyle \text{block\_writer} \quad \text{iff} \quad \text{avail} < n

消息队列

如果觉得传送带太简陋，不妨升级成前台信箱：每封邮件都有完整信封，写清类型和长度，前台小姐按投递顺序放进信箱格，收信人随时来取，哪怕发信人早已离开。消息队列（Message Queue）就是这组信箱：内核维护一个消息链表，每条消息是带类型、长度的结构化数据块，先进先出地排队。

相比管道，消息队列的收益是“解耦”。管道要求读写双方同时在线，一方退出，另一方就会收到 EOF 或 SIGPIPE；而消息队列只要内核还在，发信人 msgsnd 投递完就可以忙别的，收信人 msgrcv 可以按自己的节奏取信，甚至能按消息类型精准挑选（比如只读 type=1 的消息）。这在工程中非常像异步任务队列：任务和任务之间不必等待对方处理完毕。

不过信箱格终究有限，内核必须为队列设上限，防止某个进程狂发邮件撑爆内存。设第 i 条消息长度为 len(m_i)，则有界约束为：

用前台信箱的视角回看：消息队列适合“通知式”“任务式”的通信，天然带边界和类型语义，是微服务各组件之间常见的中间层雏形。

∑i=1klen(mi)≤MAX_QUEUE_BYTES\displaystyle \sum_{i=1}^{k} \text{len}(m_i) \le \text{MAX\_QUEUE\_BYTES}
  1. 求和累计长度把队列中现存 k 条消息的长度逐一累加，得到当前占用的总字节数。
    ∑i=1klen(mi)\displaystyle \sum_{i=1}^{k} \text{len}(m_i)
  2. 队列上限 MAX_QUEUE_BYTES内核规定的消息队列最大容量，通常是系统参数，超出后 msgsnd 会阻塞或返回错误。
    MAX_QUEUE_BYTES\displaystyle \text{MAX\_QUEUE\_BYTES}
  3. 约束关系只有累计长度不超过上限，投递才能成功；这保证单个队列不会无限吞噬内存，也隐含了生产者必须慢下来等待消费者的节奏。
    ≤\displaystyle \le

共享内存

写字楼里最火的设施是走廊尽头的公共白板。管理处（内核）做的唯一一件事，是帮你把白板“装”到两间办公室的墙壁上——此后你写黑板、他看黑板，整个过程没有任何人替你们传话。这就是共享内存：通过 shmget 申请一段物理内存，再用 shmat 把它映射到各进程自己的虚拟地址空间。映射建立后，读写共享区就是普通的 load/store 指令，不再触发系统调用，数据拷贝次数从管道/队列的两次降为零，所以它是速度最快的 IPC。

映射的本质是分页机制：每个进程的虚拟地址经由各自的页表指向同一个物理页帧。记进程 P 访问共享区域的虚拟地址为 VA_P，其页表项 PTE 指向物理帧 Frame_k：

白板好用，麻烦也大。若 A 正写到一半，B 冲上来涂改，整块板就花掉了——这就是共享内存必须搭配信号量或锁的原因。它不适合传递“一条通知”这种小消息，而适合搬运大数据块，比如模型参数、图片 buffer。记住写字楼的教训：白板本身不设防，防的是使用白板的人。

VAP=BaseP+offset,Framek←PTE[VAP]\displaystyle \text{VA}_P = \text{Base}_P + \text{offset}, \qquad \text{Frame}_k \leftarrow \text{PTE}[\text{VA}_P]
  1. 共享虚拟地址进程 P 把共享区安插在自己的地址空间中，从 Base_P 开始偏移 offset 处访问它。
    VAP=BaseP+offset\displaystyle \text{VA}_P = \text{Base}_P + \text{offset}
  2. 页表项翻译CPU 通过进程 P 的页表项 PTE 查询 VA_P，发现该虚拟页已被映射到一个共享物理帧。
    PTE[VAP]\displaystyle \text{PTE}[\text{VA}_P]
  3. 同一物理帧 Frame_k两个进程的页表不同，但最终都解析到 Frame_k，于是“各写各的地址，实为同一块内存”，零拷贝由此而来。
    Framek←PTE[VAP]\displaystyle \text{Frame}_k \leftarrow \text{PTE}[\text{VA}_P]

信号量机制

会议室门口挂着一块数字门牌，上面写着当前可用座位数。想进门的部门必须先把数字减 1，若结果不小于 0，进去；若为负数，说明坐满了，在外面排队。开完会出来再把数字加 1。这块“门牌 + 排队规则”就是信号量（Semaphore），由 Dijkstra 提出，是解决共享白板冲突的关键工具。它本质是个非负整数和一个等待队列，只提供两个原子操作：P 操作（proberen，检测，也叫 down）和 V 操作（verhogen，增加，也叫 up）。

P 与 V 的语义如此对称，以至于可以直接写成：

回到门牌：初值设为 1，信号量就成了互斥锁（同一时刻只放一个人进白板间）；初值设为 5，就允许最多 5 个进程同时使用资源。但门牌也有致命陷阱——若部门 A 先占住 1 号会议室再去等 2 号，部门 B 反着来，两个部门就会互相卡死。这就是死锁，工程上必须通过统一加锁顺序来规避。

P(s): s←s−1;if s<0 then block\displaystyle P(s):\ s \leftarrow s - 1; \quad \text{if } s < 0 \text{ then block}
V(s): s←s+1;if s≤0 then wakeup\displaystyle V(s):\ s \leftarrow s + 1; \quad \text{if } s \le 0 \text{ then wakeup}
  1. P 操作减一进程请求一个资源，先把计数值 s 减 1。
    s←s−1\displaystyle s \leftarrow s - 1
  2. P 的阻塞判定若减后 s < 0，说明资源已耗尽，当前进程进入等待队列，直到别人释放资源。
    if s<0 then block\displaystyle \text{if } s < 0 \text{ then block}
  3. V 操作加一进程释放一个资源，把计数加 1。
    s←s+1\displaystyle s \leftarrow s + 1
  4. V 的唤醒判定若加后 s ≤ 0，表示仍有进程悬在等待队列中，必须唤醒其中一个，把资源交给它。
    if s≤0 then wakeup\displaystyle \text{if } s \le 0 \text{ then wakeup}

套接字通信

前面所有设施都在同一栋楼里。如果分公司在其他城市，传送带、信箱、白板全都够不着，唯一的选项是拉一根电话线：套接字（Socket）。套接字是网络通信的端点，由 IP 地址和端口号唯一标识。进程 A 发起“呼叫”（connect），内核的协议栈负责把数据封装成网络包，跨越物理链路后在对端解封装，再交给进程 B。它是唯一能突破单机边界、实现跨主机通信的 IPC。

电话线也有两种打法。TCP 像一次正式通话：先拨号（三次握手）确认双方都在，然后逐句确认“你听清了吗”，确保数据不丢、不乱序，代价是额外的往返确认开销；UDP 则像对讲机：喊一嗓子就完事，不保证对方听到，但延迟低、开销小。三次握手的过程可以视作一个三段式事务：

值得一提的是，就算在同一台机器上，进程间也能用套接字通信：本地套接字（Unix Domain Socket）不走网络协议栈，直接在内核内搬运数据，比走 TCP 环回还快。它相当于在楼内也牵了专线，省去所有网络封装开销，分布式数据库和容器编排组件很喜欢用它。

Client→SYNServer,Server→SYN+ACKClient,Client→ACKServer\displaystyle \text{Client} \xrightarrow{SYN} \text{Server}, \quad \text{Server} \xrightarrow{SYN+ACK} \text{Client}, \quad \text{Client} \xrightarrow{ACK} \text{Server}
  1. SYN 请求连接客户端先发送同步报文 SYN，声明“我想建立连接”。
    Client→SYNServer\displaystyle \text{Client} \xrightarrow{SYN} \text{Server}
  2. SYN+ACK 应答服务端收到后同时回复 SYN+ACK，表示“收到，我也准备好”。
    Server→SYN+ACKClient\displaystyle \text{Server} \xrightarrow{SYN+ACK} \text{Client}
  3. ACK 确认客户端再回一个 ACK，双方确认完毕，连接建立，随后进入可靠数据传输阶段。
    Client→ACKServer\displaystyle \text{Client} \xrightarrow{ACK} \text{Server}

综合对比

现在把整栋写字楼的设施放在一起比较。哪种最快？永远是共享内存——没有系统调用、没有拷贝。管道次之，它只有内核缓冲区一次中转；消息队列介于管道和套接字之间，多了一层消息结构的维护；套接字由于要过协议栈（即使是本地套接字），延迟最高。一个经验性的成本模型可以写成线性函数：固定开销 a 加上随数据量线性增长的 b·n：

除了速度，还有三把尺子：一是能否跨机——只有套接字能；二是数据是否有边界——管道是裸字节流，消息队列和套接字（UDP）有边界；三是安全与同步——共享内存最快但最需自觉，内核只在建立映射时校验权限，之后的操作完全依赖进程间的同步约定。选型没有银弹，只能按场景打分：同机、大块、高频 → 共享内存；同机、流式、单向 → 管道；同机、任务式、要解耦 → 消息队列；跨机 → 套接字。

C(n)=a+b×n,ashm≪apipe<aqueue<asocket\displaystyle C(n) = a + b \times n, \qquad a_{\text{shm}} \ll a_{\text{pipe}} < a_{\text{queue}} < a_{\text{socket}}
  1. 线性开销模型通信总成本 C(n) 由每次通信的固定开销 a 和随消息长度 n 增长的可变开销 b×n 构成。
    C(n)=a+b×n\displaystyle C(n) = a + b \times n
  2. 固定开销 a 排序共享内存的 a 最小（映射建立后几乎为零），管道其次，消息队列和套接字因为要附加协议或结构处理而更大。
    ashm≪apipe<aqueue<asocket\displaystyle a_{\text{shm}} \ll a_{\text{pipe}} < a_{\text{queue}} < a_{\text{socket}}
  3. 可变项 b×n数据量越大，拷贝和传输时间越明显；但共享内存的可变项也远小于需要多次拷贝的消息传递。
    b×n\displaystyle b \times n

工程实战

把整本协作手册落到真实项目里，最经典的范式是“生产者—消费者”。假设一个 AI 训练数据管道：生产者进程负责读取海量图片并做预处理，消费者进程负责喂给 GPU。两者之间往往是一块有界共享缓冲区，配合信号量管控产量和消费量。设缓冲区容量为 N，生产者和消费者各维护一个计数器，再加上互斥锁保护读写位置，三个信号量的初始值即为：

Nginx 是共享内存 + 信号量的经典案例：多 worker 进程通过共享内存维护连接计数和负载均衡状态，用自旋锁/信号量保证计数器原子性，避免每个请求都走内核消息队列。Kafka 则相反，它用套接字跨机传输日志流，靠 TCP 保证消息不丢。选型原则其实就三句话：先问数据是否必须跨机器；再问数据块是大是小、延迟是否敏感；最后问双方节奏是否同步。答案清楚了，写字楼里的哪间设施也就呼之欲出了。

empty=N,full=0,mutex=1\displaystyle \text{empty} = N, \qquad \text{full} = 0, \qquad \text{mutex} = 1
  1. empty 空位计数初始为 N，生产一个数据就要 P(empty) 消耗一个空位，缓冲满时阻塞生产者。
    empty=N\displaystyle \text{empty} = N
  2. full 满位计数初始为 0，消费者取数据前 P(full)，缓冲空时阻塞消费者。
    full=0\displaystyle \text{full} = 0
  3. mutex 互斥锁初值为 1 的信号量，保护缓冲区头尾指针不被并发写坏。
    mutex=1\displaystyle \text{mutex} = 1

AI 应用场景

多进程数据管道

阶段：数据预处理与特征工程

解决的问题：单进程预处理图片/文本太慢，传统方式用磁盘中间文件传递数据，I/O 频繁拖慢训练。用 multiprocessing.Queue 或共享内存做 IPC，生产者进程负责读取原始数据、消费者进程负责特征计算，双方不等待磁盘，吞吐量提升数倍。

具体案例：某 CV 团队做亿级图片清洗，用两个 worker：一个进程批量解压图片写入共享内存环形缓冲，一个进程读取后做 resize 和归一化，再用信号量控制缓冲水位，GPU 利用率从 60% 升到 95%。

分布式训练梯度聚合

阶段：模型训练与分布式通信

解决的问题：多卡训练需要把每张 GPU 算出的梯度汇总到所有节点，传统做法走 TCP 套接字，延迟高。NCCL 等通信库在同机内优先用共享内存 + 锁，跨机用 RDMA 套接字，把 all-reduce 时间压到最低。

具体案例：8 卡单机训练大语言模型，每轮迭代的梯度聚合时间从走 TCP 环回的 80ms 降到共享内存方案的 12ms，整体训练提速约 15%。

微服务推理网关

阶段：模型推理服务部署

解决的问题：推理服务拆分出“请求预处理”和“模型推理”两个微服务，传统 HTTP 轮询开销大。用 gRPC 或本地套接字做 IPC，同一节点上的服务间通信延时可降到微秒级。

具体案例：某推荐系统把特征拼接服务与推理服务部署在同一台机器，二者改用 Unix Domain Socket 通信，P99 延迟从 8ms 降到 1.2ms，省下的时间用来加长上下文窗口。

Python 演示

python37 行
import multiprocessing as mpimport time def producer(conn_out, queue, shm, lock, size):    for i in range(size):        conn_out.send(("task", i))          # 管道：写字节流        queue.put("message-%d" % i)          # 消息队列：投递信件        with lock:            shm.buf[0:1] = bytes([48 + i])   # 共享内存：写白板        time.sleep(0.05) def consumer(conn_in, queue, shm, lock, size):    got = []    for _ in range(size):        if conn_in.poll(1):            got.append(conn_in.recv())    for _ in range(size):        got.append(queue.get())    with lock:        got.append(shm.buf[0:1].decode())    print("consumer collected:", got) if __name__ == "__main__":    conn_a, conn_b = mp.Pipe()    queue = mp.Queue(10)    shm = mp.shared_memory.SharedMemory(create=True, size=1)    lock = mp.Lock()    size = 5    p = mp.Process(target=producer, args=(conn_a, queue, shm, lock, size))    c = mp.Process(target=consumer, args=(conn_b, queue, shm, lock, size))    p.start()    c.start()    p.join()    c.join()    shm.close()    shm.unlink()    print("IPC demo finished")
目的：用 Python 标准库的 multiprocessing 在真实代码中演示管道、消息队列、共享内存和信号量（Lock）四种 IPC 的协作方式，模拟生产者把数据经三种通道送给消费者。
  1. conn_a, conn_b = mp.Pipe()创建匿名管道，返回两个连接对象，一个用于发送、一个用于接收。
  2. queue = mp.Queue(10)创建有界消息队列，容量 10 条，超限时生产者自动阻塞。
  3. shm = mp.shared_memory.SharedMemory(create=True, size=1)在共享内存中申请 1 字节空间，返回映射对象。
  4. lock = mp.Lock()创建互斥锁（初值为 1 的信号量），保护共享内存的写入。
  5. with lock: shm.buf[0:1] = bytes([48 + i])加锁后向共享内存写入 ASCII 码，避免和消费者读操作竞争。
  6. mp.Process(target=producer, args=(conn_a, queue, shm, lock, size))创建独立进程，把四种 IPC 对象作为参数传进去。
  7. shm.unlink()所有进程结束后由主进程显式删除共享内存段，防止内核资源泄漏。

常见误区

误区我写多线程程序时，两个线程要共享数据，是不是也得用管道或消息队列？要不数据不会互相污染吗？

正解线程属于同一个进程，天然共享进程的地址空间——文件柜本来就是同一个，直接读全局变量即可。线程间需要的是锁和条件变量（同步），而不是 IPC（通信）。只有进程之间因为页表隔离才需要 IPC。把 IPC 用在多线程上，等于在自家同一间办公室还装传送带，纯属多此一举。

为何常见：初学者常把“并发”和“进程”混为一谈，看到共享数据就想到通信，忽略了线程和进程最本质的地址空间差异。

误区共享内存最快，那所有进程间通信都该用它，其他方式都该淘汰。

正解共享内存的“快”是有前提的——双方必须常驻同一台机器，且愿意自己维护同步。一旦涉及跨机器，共享内存立刻失效；一旦消息很小很零碎，建映射的开销反而比走一次管道还贵；一旦忘记加锁，竞态条件会导致数据静默损坏，比慢更可怕。

为何常见：性能对比表格容易让人只看“延迟最低”一栏，忽略了选型里“是否跨机”“消息是否有边界”“同步成本”这些隐性维度。

误区Linux 的匿名管道只能父子进程之间通信，其他进程想用管道没门。

正解准确地说，匿名管道要求通信双方有“亲缘关系”——因为管道本身没有名字，子进程必须通过 fork 继承父进程的文件描述符才能拿到管道的两端。但真正任意进程都能用的是命名管道（FIFO）：它有一个文件系统路径做名字，任何进程都能按路径打开它。所以“管道”家族其实有两套设施，能力边界完全不同。

为何常见：教材先讲 fork + pipe 的经典父子示例，容易让人把“示例场景”误当成“能力上限”。

误区信号量不就是锁吗？P 就是加锁，V 就是解锁，两者没区别。

正解互斥锁只是信号量初值为 1 的特例。初值为 N 的信号量允许多达 N 个进程同时进入临界区，这是“资源计数”语义，互斥锁做不到；此外信号量的 P/V 可以在不同进程间交叉调用（一个进程 P、另一个进程 V），而标准互斥锁要求加锁者与解锁者是同一线程。把信号量窄化为锁，就会错过它在生产者消费者模型中管理“空位/满位”的妙用。

为何常见：日常写代码时 Lock 用得多，而信号量在语言库里出场频率低，导致许多人对它的多值语义毫无概念。

面试题

Q1. 在 Linux 中，创建匿名管道所使用的系统调用是？

单选题 · easy

  • A.fork()
  • B.pipe()← 正确答案
  • C.socket()
  • D.shmget()

答案：B。pipe() 创建匿名管道并返回读、写两个文件描述符，这是管道的唯一入口。fork() 用于创建子进程；socket() 创建套接字端点；shmget() 申请共享内存段。好比写字楼里接传送带要找管理处登记 pipe，而不是直接去开门或拉电话线。

Q2. 下列哪种 IPC 方式支持跨主机通信？

单选题 · easy

  • A.匿名管道
  • B.共享内存
  • C.套接字← 正确答案
  • D.消息队列

答案：C。套接字使用 IP + 端口标识端点，数据经网络协议栈传输，是唯一能跨机器的 IPC。管道、共享内存和消息队列都依赖同一个内核地址空间，物理上被限制在单机内。这就像只有电话线能联系分公司，传送带和信箱都离不开本栋写字楼。

Q3. 各进程拥有独立虚拟地址空间、无法直接访问对方内存的根本原因是？

单选题 · easy

  • A.内核调度策略不同
  • B.每个进程有独立的页表← 正确答案
  • C.CPU 缓存不共享
  • D.进程优先级不同

答案：B。每个进程都有一套独立页表，虚拟地址到物理地址的映射互不相同，A 进程的虚拟地址在 B 进程的页表中可能根本没有映射。所以跨进程必须借助 IPC。好比每间办公室的墙壁和文件柜位置不同，你无法隔墙取物。

Q4. 共享内存比管道快的最主要原因是？

单选题 · mid

  • A.不需要内核参与
  • B.读写数据时避免用户态与内核态之间的多次拷贝← 正确答案
  • C.数据不存放在内存中
  • D.完全没有同步开销

答案：B。共享内存建立映射后，读写就是普通内存指令，省去了管道那种“用户态→内核态→用户态”的两次拷贝。注意内核在建立映射时仍需参与，所以 A 不对；共享内存仍需同步，D 也不对。

Q5. 对初始值为 1 的信号量连续执行两次 P 操作，第二次 P 操作后信号量值为 -1，这表示？

单选题 · mid

  • A.还有一个资源可用
  • B.有一个进程正在等待该信号量← 正确答案
  • C.信号量发生了死锁
  • D.允许一个进程额外进入

答案：B。P 操作是“先减一，再判断”。第一次 P 把 1 变 0 让当前进程进入临界区；第二次 P 把 0 变 -1 且小于 0，说明资源耗尽，第二个请求进程进入等待队列。s 的绝对值就是等待进程数，-1 表示正好一个进程在等。

Q6. 消息队列相比管道最核心的优势是？

单选题 · mid

  • A.传输速度更快
  • B.消息有边界和类型，支持按类型接收← 正确答案
  • C.可以跨主机通信
  • D.不需要内核参与

答案：B。消息队列以“消息”为单位存储，每条消息自带类型和长度，接收方可以按类型读取；而管道是裸字节流，没有消息边界，读多少完全由内核决定。速度上消息队列并不比管道快，且二者都不能跨主机，D 明显错误。

Q7. 某信号量初始值为 5，若不考虑死锁，最多允许多少个进程同时进入临界区？

单选题 · hard

  • A.1
  • B.5← 正确答案
  • C.无限
  • D.0

答案：B。信号量的初值代表可用资源数量。每次 P 操作使值减 1，值仍大于等于 0 就放行，因此初值 5 最多允许 5 个进程同时进入临界区。若初值为 1 才退化为互斥锁，所以 A 不对。

Q8. 共享内存必须与哪些机制配合才能安全使用？

多选题 · mid

  • A.信号量← 正确答案
  • B.互斥锁← 正确答案
  • C.管道
  • D.消息队列

答案：AB。共享内存本身不提供任何互斥语义，多个进程同时读写会造成竞态，必须配合信号量或互斥锁来约定“先写后读”。管道和消息队列是另一种通信设施，不能保护共享内存不被并发写坏。

Q9. 下列哪些做法可以有效避免多进程死锁？

多选题 · hard

  • A.所有进程按固定顺序申请资源← 正确答案
  • B.使用 trylock，申请失败时主动释放已持有的锁← 正确答案
  • C.把信号量初值从 1 改成 2
  • D.一次性申请全部所需资源← 正确答案

答案：ABD。死锁源于“循环等待”。统一加锁顺序（A）打破循环；trylock 加回退（B）打破持有并等待；一次申请全部资源（D）同样消除循环等待。而把初值从 1 改成 2 只是增加并发度，不改变加锁顺序，无法避免死锁。

Q10. 关于共享内存映射，下列说法正确的有？

多选题 · extreme

  • A.多个进程通过各自页表映射到同一物理页帧← 正确答案
  • B.共享内存一定启用写时复制机制
  • C.映射建立后读写数据无需系统调用，但仍需同步← 正确答案
  • D.传输大数据块时通常比管道延迟更低← 正确答案

答案：ACD。共享内存的本质是让多个进程的页表项指向同一个物理页帧，A 正确。MAP_SHARED 映射不启用写时复制，写时复制是 MAP_PRIVATE 的语义，B 错误。映射后读写就是访存指令，不需要系统调用，但要靠信号量同步，C 正确。大数据块场景下共享内存免去两次拷贝，延迟显著低于管道，D 正确。