Python 进程间通信全解析：Queue、Pipe、共享内存到 Socket，IPC 选型与实战指南

Python 进程间通信全解析：Queue、Pipe、共享内存到 Socket，IPC 选型与实战指南

在 Python 编程中，当程序从一个简单脚本逐渐成长为数据处理系统、自动化平台、Web 后端、AI 推理服务或者高性能计算程序时，我们很快会碰到一个绕不开的问题：

多个进程之间，怎样交换数据？

例如，一个进程负责读取文件，一个进程负责图像计算，另一个进程负责把结果写入数据库：

文件读取进程
│
▼
图像处理进程
│
▼
结果存储进程

它们必须“说话”。

这就是：

IPC
Inter-Process Communication
进程间通信

Python 为此准备了非常丰富的工具：

multiprocessing.Queue
multiprocessing.Pipe
multiprocessing.Value
multiprocessing.Array
multiprocessing.Manager
multiprocessing.shared_memory
mmap
socket

除此之外，还有：

Lock
Event
Semaphore
Condition

用于解决多个进程访问共享资源时的同步问题。

这些 API 单独看都不难，真正困难的是：

什么时候用 Queue？什么时候用 Pipe？为什么共享内存通常更快？Manager 为什么方便却不能滥用？大数据究竟应该传过去，还是让进程共同访问？

这篇 Python 教程就从工程实践出发，把 Python 进程间通信真正讲透。

一、为什么进程之间需要专门通信？

首先要理解进程和线程的一个根本区别。

线程通常运行在同一个进程中，可以访问同一个地址空间：

Process
├── Thread A
├── Thread B
└── Thread C
│
└── 共享内存空间

而普通进程则拥有彼此独立的地址空间：

Process A
└── Memory A

Process B
└── Memory B

Process C
└── Memory C

因此，一个进程中存在：

data = [1, 2, 3]

另一个独立进程默认并不能像线程一样直接操作这个普通 Python 对象。

multiprocessing 因而提供了 Queue、Pipe、共享对象、Manager 等机制，使进程能够传递消息或者共享特定数据。Python 官方文档也将 multiprocessing 定义为基于进程的并行机制，并提供 Queue、Pipe、同步原语及共享状态等能力。 (Python documentation)

理解 IPC，可以先把方法分成三大类：

第一类：传消息
Queue / Pipe / Socket

第二类：共享数据
Value / Array / SharedMemory / mmap

第三类：协调访问
Lock / Event / Semaphore / Condition

这三个概念千万不要混在一起。

二、方式一：multiprocessing.Queue——最推荐的通用 IPC

如果一个初学者问：

Python 两个进程交换数据，应该先学什么？

我的答案通常是：

multiprocessing.Queue

Queue 是一个非常实用的生产者—消费者模型。

例如：

生产者进程
│
│ put()
▼
┌───────┐
│ Queue │
└───────┘
│
│ get()
▼
消费者进程

来看一个完整例子：

from multiprocessing import Process, Queue

def producer(queue):
for number in range(5):
print(f"生产：{number}")
queue.put(number)

queue.put(None)

def consumer(queue):
while True:
item = queue.get()

if item is None:
break

print(f"消费：{item}")

if __name__ == "__main__":
queue = Queue()

p1 = Process(target=producer, args=(queue,))
p2 = Process(target=consumer, args=(queue,))

p1.start()
p2.start()

p1.join()
p2.join()

其中：

queue.put(data)

负责发送数据，而：

queue.get()

负责接收数据。

这里最后放入：

None

是一种非常常见的“哨兵值”设计，告诉消费者：

没有更多任务了，可以退出。

官方文档指出，multiprocessing.Queue 是面向进程安全使用的队列，其底层使用 Pipe 以及锁/信号量等机制；放入 Queue 的 Python 对象会被序列化后传输。 (Python documentation)

三、Queue 为什么如此适合生产者—消费者？

假设我们有一个图片处理系统：

主进程
│
│ 图片路径
▼
Task Queue
│
├── Worker 1
├── Worker 2
├── Worker 3
└── Worker 4

主进程只负责生产任务：

task_queue.put("001.jpg")
task_queue.put("002.jpg")
task_queue.put("003.jpg")

Worker 从 Queue 中不断取任务：

filename = task_queue.get()

处理完成后，可以再建立：

result_queue

形成：

Task Queue
│
┌──────────┼──────────┐
▼ ▼ ▼
Worker1 Worker2 Worker3
│ │ │
└──────────┼──────────┘
▼
Result Queue
│
▼
主进程

这是非常经典的多进程任务流水线。

Queue 特别适合：

• 多生产者、多消费者；
• Worker Pool；
• 后台任务系统；
• 图片批处理；
• 日志收集；
• 数据 ETL；
• CPU 任务分发。

四、Queue 的一个重要成本：序列化

使用 Queue 时有一个特别容易被忽视的问题。

假设：

queue.put(data)

这里的 data 是一个复杂 Python 对象。

它并不是简单地让另一个进程获得当前变量引用。

Queue 中的对象需要经过序列化，再由另一端重新构造。官方 multiprocessing 文档明确说明，通过 Queue 传递的对象会被序列化。 (Python documentation)

所以：

Python Object
│
▼
serialization
│
▼
IPC
│
▼
deserialization
│
▼
Python Object

如果传输的是：

{"id": 1001, "filename": "a.jpg"}

问题不大。

但如果不停传递几百 MB 的大数组：

queue.put(huge_array)

那么：

序列化成本
+
内存复制
+
进程通信
+
反序列化成本

就可能非常可观。

因此一个重要的 Python 最佳实践是：

Queue 适合传任务和消息，不一定适合频繁搬运超大数据块。

大数据场景，我们很快会看到更好的方案——共享内存。

五、方式二：Pipe——简单直接的点对点通信

第二种非常经典的方法是：

multiprocessing.Pipe

例如：

from multiprocessing import Process, Pipe

def worker(connection):
connection.send({
"status": "success",
"result": 100
})

connection.close()

if __name__ == "__main__":
parent_conn, child_conn = Pipe()

process = Process(
target=worker,
args=(child_conn,)
)

process.start()

result = parent_conn.recv()

print(result)

process.join()

Pipe() 会返回两个端点：

parent_conn <==========> child_conn

默认情况下，它是双向通信的。

也可以创建单向 Pipe：

receiver, sender = Pipe(duplex=False)

官方文档说明，Pipe() 返回一对 Connection 对象；默认 duplex=True 时可以双向通信，而 send() 发送的 Python 对象同样会经过序列化，在另一端由 recv() 重建。 (Python documentation)

六、Queue 和 Pipe 到底怎么选？

这是面试和实际开发中都非常常见的问题。

简单来说：

两个明确进程之间
↓
Pipe

多个生产者 / 消费者
↓
Queue

对比：

官方文档还特别提醒：不要让多个进程同时读写 Pipe 的同一个端点，否则存在数据损坏风险；不同进程分别使用不同端点则没有这一问题。 (Python documentation)

所以 Pipe 最适合：

Process A
│
▼
Process B

而 Queue 更适合：

Queue
/ | \\
/ | \\
▼ ▼ ▼
Worker1 Worker2 Worker3

七、方式三：Value 与 Array——共享简单数据

如果进程之间只是需要共享：

一个数字
一个状态
一小段固定数组

并不一定需要 Queue。

multiprocessing 提供：

Value
Array

例如共享计数器：

from multiprocessing import Process, Value

def worker(counter):
for _ in range(10000):
with counter.get_lock():
counter.value += 1

if __name__ == "__main__":
counter = Value("i", 0)

processes = [
Process(target=worker, args=(counter,))
for _ in range(4)
]

for process in processes:
process.start()

for process in processes:
process.join()

print(counter.value)

这里：

Value("i", 0)

表示创建一个共享整数。

"i" 可以理解为 C 类型中的：

signed int

Array 则用于共享多个值：

from multiprocessing import Array

numbers = Array("i", [1, 2, 3, 4, 5])

multiprocessing 官方文档提供了共享 ctypes 对象和同步包装能力；使用同步版本时可以通过 Lock/RLock 协调访问。 (Python documentation)

八、为什么共享数据必须考虑锁？

想象两个进程同时执行：

counter.value += 1

从程序员视角，这像“一步”。

但底层逻辑可能接近：

读取 counter
↓
加 1
↓
写回 counter

此时：

Process A：读取 10
Process B：读取 10

Process A：写 11
Process B：写 11

最终得到：

11

而不是：

12

这就是：

Race Condition
竞争条件

解决方式通常是锁：

with counter.get_lock():
counter.value += 1

因此请记住：

共享内存解决的是“大家能不能看到同一份数据”，锁解决的是“大家怎么安全地修改这份数据”。

这是两个完全不同的问题。

九、方式四：SharedMemory——大数据 IPC 的重要利器

当数据越来越大，Queue 的序列化和复制成本可能开始变得明显。

这时可以考虑：

multiprocessing.shared_memory

Python 的 SharedMemory 允许不同进程连接到同一个共享内存区域。

结构变成：

Process A ──────┐
│
▼
Shared Memory
▲
│
Process B ──────┤
│
Process C ──────┘

而不是：

Process A
│
│ serialize + copy
▼
Process B

官方文档指出，共享内存允许不同进程直接访问共同的内存区域，从而避免必须通过磁盘、Socket 或其他需要序列化和复制数据的通信方式传送整份数据，在合适场景下可带来显著性能收益。 (Python documentation)

十、SharedMemory 实战

来看一个简单例子：

from multiprocessing import Process
from multiprocessing.shared_memory import SharedMemory

def worker(name, size):
shm = SharedMemory(name=name)

try:
data = shm.buf[:size]

print(
"子进程计算结果：",
sum(data)
)
finally:
shm.close()

if __name__ == "__main__":
source = bytes(range(100))

shm = SharedMemory(
create=True,
size=len(source)
)

try:
shm.buf[:len(source)] = source

process = Process(
target=worker,
args=(shm.name, len(source))
)

process.start()
process.join()

finally:
shm.close()
shm.unlink()

关键在于：

shm.name

另一个进程通过共享内存名字：

SharedMemory(name=name)

连接同一块共享区域。

官方文档规定，使用完共享内存后应通过 close() 关闭当前进程的访问句柄；当整个共享内存区域彻底不再需要时，应调用 unlink() 清理它。 (Python documentation)

十一、SharedMemory 特别适合什么？

典型场景包括：

图像数据
视频帧
大型数组
AI 推理输入
科学计算矩阵
高频实时数据

假设一个数据块有：

500 MB

如果不断通过：

queue.put(data)

在多个进程之间传递，会产生比较明显的数据搬运成本。

一种更好的架构是：

Shared Memory
┌──────────────┐
│ 500MB 数据 │
└──────────────┘
▲ ▲ ▲
│ │ │
Worker Worker Worker

Queue 只传：

{
"shm_name": "…",
"offset": 1000,
"length": 20000
}

也就是：

小消息走 Queue，大数据放 SharedMemory。

这是非常值得掌握的一种生产环境设计思想。

十二、方式五：Manager——最好用，但不是最快

Python 还提供了一个对初学者特别友好的工具：

multiprocessing.Manager

它可以创建：

dict
list
Namespace
Queue
Lock

等可以跨进程使用的代理对象。

例如：

from multiprocessing import Process, Manager

def worker(shared_dict, index):
shared_dict[index] = index * index

if __name__ == "__main__":
with Manager() as manager:

result = manager.dict()

processes = []

for i in range(5):
process = Process(
target=worker,
args=(result, i)
)

process.start()
processes.append(process)

for process in processes:
process.join()

print(dict(result))

输出类似：

{
0: 0,
1: 1,
2: 4,
3: 9,
4: 16
}

它看起来非常舒服。

因为程序员可以像访问普通：

dict

一样访问：

manager.dict()

十三、Manager 为什么不能滥用？

Manager 的便利是有成本的。

它不是让多个进程神奇地直接操作同一个普通字典。

Manager 背后会由管理进程维护真正的对象，其他进程通过代理与其交互。Python 官方 multiprocessing 文档将 Manager 描述为一种通过服务进程管理共享对象、其他进程通过代理访问它们的机制。 (Python documentation)

大致可以理解成：

Worker A ──┐
Worker B ──┼── Proxy ── Manager Process ── dict
Worker C ──┘

因此下面的代码：

shared_dict[key] = value

背后并不像普通本地字典访问那么简单。

所以建议：

Manager 适合

共享状态不大
操作频率不高
开发效率比极限性能更重要
数据结构比较复杂

Manager 不适合

每秒几十万次共享字典读写
超大数组
极低延迟场景
高吞吐数值计算

如果性能很敏感，应优先考虑：

SharedMemory
+
Queue
+
合理的数据布局

十四、方式六：mmap——内存映射文件

Python 还有一个容易被忽视但非常强大的标准库：

mmap

它可以把文件映射到内存空间。

映射后可以像操作：

bytearray

一样访问内容。

Python 官方文档说明，mmap 对象同时具有类似文件和字节数组的行为，可进行索引、切片、读写及 seek 等操作。 (Python documentation)

例如：

import mmap

with open("data.bin", "r+b") as file:

mm = mmap.mmap(
file.fileno(),
0
)

print(mm[:10])

mm[0:5] = b"HELLO"

mm.flush()
mm.close()

多个进程映射同一个文件，就可以围绕同一份底层数据进行协作。

十五、mmap 和 SharedMemory 有什么区别？

它们看起来很像，但目标并不完全一样。

SharedMemory

更加偏向：

运行时临时共享数据

例如：

AI 推理缓冲区
图像帧
大型 NumPy 数据
实时计算中间结果

mmap

更加适合：

文件本身就是数据源
超大文件随机读取
需要文件持久化
多个进程共同映射同一个文件

可以简单记忆：

数据主要在内存
↓
SharedMemory

数据主要来自文件
↓
mmap

当然，真正的性能还取决于访问模式、操作系统页面缓存、数据规模以及同步策略，需要通过 benchmark 判断。

十六、方式七：Socket——不只一台机器也能通信

前面的 Queue、Pipe、SharedMemory，大多重点解决：

同一台计算机上的多进程通信

如果变成：

服务器 A
│
│ 网络
▼
服务器 B

则：

socket

开始发挥作用。

Python 标准库直接提供 BSD Socket 接口，可以进行 TCP、UDP 等网络通信。官方 IPC 文档也明确区分了只适用于本机进程的机制和能够支持网络通信的机制。 (Python documentation)

例如：

Process A
│
│ TCP Socket
▼
Process B

甚至：

北京服务器
│
▼
上海服务器

也可以通信。

Python 官方 Socket HOWTO 对本机 IPC 的建议也很有代表性：如果只是同一台机器上两个进程追求高速通信，应优先考虑 Pipe 或 Shared Memory；如果使用网络 Socket，则本机通信通常绑定 localhost。 (Python documentation)

十七、Socket 特别适合什么？

例如：

微服务
分布式计算
独立服务进程
模型推理服务器
数据库客户端
RPC
跨主机程序

与 SharedMemory 相比：

SharedMemory
↓
速度快
↓
通常局限本机

而：

Socket
↓
网络成本更高
↓
但可以跨机器

这本质上是在交换：

性能
↕
灵活性

十八、别忘了另一半 IPC：进程同步

谈 IPC 不能只讨论“数据怎么过去”。

还需要考虑：

两个进程什么时候可以操作数据？

例如：

Process A 正在写共享内存
Process B 同时开始读

就可能读到：

一半旧数据
+
一半新数据

因此需要同步。

Python multiprocessing 提供了与线程同步原语对应的一系列进程同步工具，例如 Lock。 (Python documentation)

常用的有：

Lock
RLock
Semaphore
Event
Condition
Barrier

十九、Lock：一次只允许一个进程进入

from multiprocessing import Lock

lock = Lock()

with lock:
# 临界区
...

逻辑就是：

Process A
│
▼
获得 Lock
│
▼
修改共享数据
│
▼
释放 Lock
│
▼
Process B 才能进入

适合保护：

计数器
共享文件
共享内存
关键配置

二十、Event：非常适合发送“开始/停止”信号

例如：

from multiprocessing import Process, Event
import time

def worker(stop_event):

while not stop_event.is_set():

print("Worker 正在运行")

time.sleep(1)

print("Worker 已停止")

if __name__ == "__main__":

stop_event = Event()

process = Process(
target=worker,
args=(stop_event,)
)

process.start()

time.sleep(3)

stop_event.set()

process.join()

它不是用来传：

500MB 图片

的。

它传递的是一种状态：

继续运行？
停止？
资源准备好了？

因此，理解 IPC 最好分两条线：

数据通信：
Queue / Pipe / SharedMemory

状态同步：
Lock / Event / Semaphore

二十一、一个生产级思路：Queue + SharedMemory

假设我们需要处理很多大图片。

一种简单但可能低效的方法：

Main Process
│
│ 整张 100MB 图片
▼
Queue
│
▼
Worker

如果图片很多，就会重复产生较大的数据搬运开销。

我们可以重新设计：

┌────────────────┐
│ Shared Memory │
│ 大型数据块 │
└────────────────┘
▲ ▲
│ │
Worker 1 Worker 2
▲ ▲
└────┬─────┘
│
Queue
│
只传任务描述

Queue 中只发送：

{
"name": shared_memory_name,
"offset": 0,
"length": 20_000_000
}

真正的大数据不移动。

这种模式可以总结成一句非常实用的话：

消息传递控制流程，共享内存承载数据。

二十二、完整小案例：共享内存 + Queue

来看一个简化版架构：

from multiprocessing import Process, Queue
from multiprocessing.shared_memory import SharedMemory

def worker(task_queue, result_queue):

while True:

task = task_queue.get()

if task is None:
break

name, size = task

shm = SharedMemory(name=name)

try:
result = sum(
shm.buf[:size]
)

result_queue.put(result)

finally:
shm.close()

if __name__ == "__main__":

task_queue = Queue()
result_queue = Queue()

data = bytes(range(100))

shm = SharedMemory(
create=True,
size=len(data)
)

try:
shm.buf[:len(data)] = data

process = Process(
target=worker,
args=(
task_queue,
result_queue
)
)

process.start()

task_queue.put(
(
shm.name,
len(data)
)
)

result = result_queue.get()

print("计算结果：", result)

task_queue.put(None)

process.join()

finally:
shm.close()
shm.unlink()

这里整个架构特别值得分析。

Queue 负责：

任务通知
任务参数
结果返回
结束信号

SharedMemory 负责：

真正的数据

最终形成：

小数据
↓
Queue

大数据
↓
SharedMemory

这比“看到 IPC 就什么都往 Queue 里塞”成熟得多。

二十三、还有一种最朴素的方法：文件

不要忘记文件本身也可以充当进程之间的数据交换媒介。

例如：

Process A
│
▼
result.json
│
▼
Process B

优点：

简单
持久化
容易调试
程序退出后数据还在

缺点：

延迟通常较高
需要考虑文件锁
并发写复杂
不适合高频小消息

因此它适合：

批处理程序
离线任务
进程之间不要求实时通信

而不是高频实时 IPC。

二十四、再进一步：Redis、RabbitMQ、Kafka 算不算？

如果系统继续扩大：

一台机器
↓
多台机器
↓
几十个服务
↓
几百个 Worker

那么 Python 自带：

multiprocessing.Queue

显然就不是整个系统的解决方案了。

此时可能使用：

Redis
RabbitMQ
Kafka
数据库
RPC
消息中间件

严格来说，这已经从“单机 IPC”逐渐进入：

Distributed Communication
分布式通信

但设计思想其实是一脉相承的：

生产者
↓
通信媒介
↓
消费者

所以掌握 Queue，对理解消息队列系统也非常有帮助。

二十五、七种 IPC 方法怎么选？

下面这张表建议保存。

二十六、一张 IPC 选型流程图

遇到问题时，可以按照下面判断：

需要进程通信
│
▼
是否跨机器？
/ \\
是 否
│ │
▼ ▼
Socket 数据很大吗？
/ \\
是 否
│ │
▼ ▼
SharedMemory 多生产者/
/ mmap 多消费者？
/ \\
是 否
│ │
▼ ▼
Queue Pipe

如果只是：

共享整数
共享小数组

可以优先考虑：

Value / Array

如果：

开发方便
>
性能要求

可以考虑：

Manager

二十七、Python 进程通信中的常见坑

坑一：认为 Queue 里的对象没有复制

错误：

两个进程拿到同一个普通 Python 对象

实际上，Queue/Pipe 发送普通 Python 对象时涉及序列化和重建。 (Python documentation)

所以大对象传输一定要测试。

坑二：共享内存没有锁就随便写

SharedMemory 解决：

能不能共享

并没有自动解决：

怎么正确并发修改

写冲突需要自己设计同步机制。

坑三：Manager 当普通 dict 疯狂访问

比如循环：

for i in range(1_000_000):
manager_dict[i] = i

每一次看似普通的访问，都可能伴随进程间代理调用。

这类代码应该通过实际 profiling 判断，并尽可能：

批量处理
减少 IPC 次数

坑四：使用 Queue 后强制 terminate Worker

官方文档特别警告，如果一个进程正在使用 Queue 时被 terminate() 或操作系统强制结束，Queue 中的数据可能被破坏，进而影响其他进程继续使用该 Queue。 (Python documentation)

因此生产环境更推荐：

发送停止信号
↓
Worker 正常退出
↓
join()

而不是：

直接杀死

坑五：忘记清理 SharedMemory

错误：

shm = SharedMemory(create=True, size=...)

然后什么都不做。

正确生命周期通常要考虑：

shm.close()
shm.unlink()

官方文档明确区分了 close() 与 unlink()：前者关闭当前访问，后者负责在共享内存彻底不再使用时请求删除资源。 (Python documentation)

资源生命周期同样是 IPC 设计的一部分。

二十八、性能优化最重要的一条原则：减少通信

很多开发者研究 IPC 时，会不断问：

Queue 和 Pipe 谁快？
SharedMemory 快多少？
Manager 慢多少？

但在真实项目里，更值得优先优化的是：

减少 IPC 次数。

假设你需要处理 100 万条数据。

方案 A：

发送 1 条
↓
处理
↓
返回 1 条

重复 100 万次

方案 B：

发送 1000 条
↓
批量处理
↓
批量返回

重复 1000 次

后者经常更符合高吞吐设计。

所以很多性能优化，本质上是：

减少序列化
+
减少系统调用
+
减少锁竞争
+
减少进程切换
+
增加批处理

而不只是换 API。

二十九、IPC 的工程设计原则

多年 Python 实战之后，我越来越倾向于下面几条原则。

1. 能不共享状态，就不要共享状态

优先：

Message Passing
消息传递

而不是到处访问公共变量。

2. 控制消息和大数据分开

推荐：

Queue
↓
任务控制

SharedMemory
↓
大数据

3. IPC 接口尽量简单

不要让不同进程之间传递特别复杂的对象关系。

最好设计成：

{
"task_id": 1001,
"input": "…",
"operation": "resize"
}

这种明确协议。

4. 必须考虑异常和进程退出

例如 Worker 崩溃后：

任务怎么办？
共享内存谁删除？
锁有没有释放？
任务是否需要重试？
主进程如何发现？

这些问题往往比：

queue.put()

本身重要得多。

5. 性能必须实测

不同程序中的瓶颈可能完全不同：

序列化
磁盘
内存带宽
锁
CPU
网络
缓存

所以不要看到：

SharedMemory 最快

就把所有代码全部改成共享内存。

复杂度本身也是成本。

三十、当前 Python 中 IPC 应该怎么学？

截至当前 Python 3.14 文档体系，标准库仍然将 multiprocessing、multiprocessing.shared_memory、subprocess 等归入并发执行工具，并将 socket、signal、mmap 等列入网络与进程间通信体系。 (Python documentation)

对于刚开始学习 Python 编程的人，我建议按照：

Queue
↓
Pipe
↓
Lock / Event
↓
Value / Array
↓
Manager
↓
SharedMemory
↓
mmap
↓
Socket

逐层深入。

不要一开始就陷入操作系统 IPC 的各种底层细节。

先真正写一个：

生产者
+
Queue
+
多个 Worker
+
结果队列

理解多进程数据流，再进一步研究共享内存，学习效果会好很多。

三十一、总结：IPC 的本质不是 API，而是数据流

回顾全文，Python 进程间通信常见方式可以概括为：

Queue
Pipe
Value
Array
Manager
SharedMemory
mmap
Socket

并配合：

Lock
Event
Semaphore
Condition

等同步机制。

如果只记住最重要的选型规则，可以浓缩成下面几句话：

普通任务分发
↓
Queue

两个进程点对点
↓
Pipe

几个简单共享变量
↓
Value / Array

复杂但不频繁的共享对象
↓
Manager

大块高频数据
↓
SharedMemory

超大文件
↓
mmap

跨主机
↓
Socket

但真正优秀的 Python 工程师不会仅仅问：

“哪个 IPC API 最快？”

而会继续问：

数据究竟有多大？

一分钟通信多少次？

数据需要复制吗？

有没有多个消费者？

是否需要跨机器？

是否需要持久化？

共享状态怎样同步？

进程突然退出以后怎么办？

能不能减少通信次数？

能不能把 1000 次小消息合并成一次批处理？

当你开始思考这些问题时，就已经从“会使用 multiprocessing”走向了真正的并发系统设计。

Python 的魅力也恰恰在这里。

你可以用几行 Queue 代码快速完成一个小工具，也可以沿着相同的思想一路深入到共享内存、高性能数据处理、AI 推理服务乃至分布式系统。

API 只是入口，数据如何流动，才是 IPC 真正的核心。

参考资料与延伸阅读

建议进一步阅读 Python 官方的 multiprocessing 文档，其中包含 Queue、Pipe、同步对象、共享 ctypes 对象和 Manager 等完整说明。 (Python documentation)

处理大块数据时，可以重点研究官方 multiprocessing.shared_memory 文档，理解共享内存的创建、连接、生命周期以及 SharedMemoryManager。 (Python documentation)

处理大型文件及文件映射数据时，可以继续阅读 Python mmap 官方文档。 (Python documentation)

如果系统开始涉及跨进程网络通信与分布式服务，则建议继续学习 Python socket 与官方 Socket Programming HOWTO。 (Python documentation)

推荐书籍包括《Python编程：从入门到实践》《流畅的Python》《Effective Python》。在掌握 Python 基础之后，还可以进一步学习操作系统中的进程、虚拟内存、文件描述符、管道、Socket 与同步原语，这些知识会让你真正理解 Python IPC API 背后的运行机制。

留给读者的两个问题

在你的 Python 实战项目中，你更常使用 Queue、Pipe，还是共享内存？

如果一个 Python 程序需要让 8 个 Worker 同时处理数 GB 的 NumPy 数据，你会选择“复制数据给每一个进程”，还是“让多个 Worker 访问共享数据”？为什么？

欢迎把自己的方案、性能数据和踩坑经历拿出来讨论。并发编程真正有意思的地方，往往并不是某一行代码怎么写，而是在各种性能、复杂度和可靠性约束之间做出那个最合适的选择。